IMHO most of your "pro" arguments are flawed, but let us discuss them one-by-one:
If the query needs to change and return a different type, we don't have to remember to rename the result variable.
If the query returns a different type in such a way that a name like
accountDetails does not fit any more, the code depending on that variable will have to be changed, even if the variable name is just
result. This is definitely easier (and thus less error prone) when the variable has a specific name. The only exception here is IMHO when there is no such code, like in a function where the
result is just returned to the caller.
That also means code reviews won't be polluted with a bunch of files that have changed due to the renaming.
If you start arguing that way, you should never ever rename any variable in your code, regardless of how badly the name was chosen, just to make code reviews more effective. Maybe you should never do any refactorings? But then don't be astonished when your code quality degrades every day.
Moreover, in your example,
result looks like a local variable, so the refactoring should typically not affect more than one file.
The job of a Web API controller isn't to know the details about what business logic is going on; it's just to invoke something and return it.
var result = mediator.Send(query).Result; is a generic, reusable piece of code, processing different kinds queries and maybe returning different things, then this line is fine. However, if that would be your situation, then you probably would not have asked the question in the first place. I guess in this case, the query is always an
accountFilter, and the result is always an
accountDetails, and as long as that is true, your variable names should express that.
Of course, as I wrote above, if the next line in your function is just
return result;, the unspecific name is ok.
If you really want to know what the line of code is doing, you can look at the context surrounding it.
Seriously? You want another maintenance programmer to decipher the surrounding context first to understand what is going on, whilst by simply picking a better name could save him half an hour of brain work? Be aware, in six months you might be the maintenance programmer for this line of code, and it will look to you as if someone else has written it first place. What would you prefer in that situation? A variable name telling you what it represents, or one for which you have to analyse the code first to be sure what it does?
So except for very simplistic cases where the whole function looks like
AccountDetails GetAccountDetails(Query query)
var result = mediator.Send(query).Result;
you will probably be better off to use a more specific name (though - even for such a simple function - a parameter name like
accountFilter instead of query will increase the readability heavily, and in this example, the
result parameter is quite useless, I would typically prefer to write