This looks elegant but somewhat generic and not telling the reader much. I’d stay away from protocols. Never did like the idea of their runtime overhead (even on the prod builds). Plain old behaviour should be fine, unless you want to go as far as possible in terms of dialyzer checks and runtime guarantees? (But I think, might be wrong, protocols don’t give you anything extra there.)
The name Respondable will net you a blank stare from me. I’d much prefer to have more granular names like Commands.Users.respond_json for example; might not be the best name as well but at least you know it deals with commands working with users (and it returns JSON). 
If I am doing a code review of a PR containing code like yours I’ll immediately return it with “I would like this code to tell me what it does without me having to dig what Respondable.to_json does and where is the code for this particular invocation”.
I agree that controllers should be lean. Contexts, domain business logic objects or whatever anyone wants to call them, are the much better way to go. What’s more, none of them should deal with Ecto directly as well but that’s another thread.
