Back when I started at Google, they at least said they actively targeted "long-tail" queries to gain market share. The thinking was that people would use a search engine until they hit some query that their usual search engine failed on. Then they'd give another search engine (perhaps Google) a try, so if you really targeted those tough queries and were at least decent at the common queries, you'd gain market share.
Though, even when I was doing indexing changes at Google, the common practice was to do A/B testing with both the most common queries and a uniformly random sample (see reservoir sampling) of queries in order to justify a go-live of indexing changes. The former explicitly over-weights common queries, and the latter still optimizes for the common case. (In case you're wondering, the worst query I had to manually check in A/B testing was [flesh hook suspension].)
Google used to turn off some of the query re-writing logic (that tries to fix your query) if you used a query operator. (It has been a while, but I think maybe even their "Kansas" user info database kept track of the last time you used an operator, and would turn off some of the cleverness if you had recently used a search operator, as it was a good signal that you were a power user capable of optimizing your own queries.) My understanding is that they don't disable any of the too-clever bits for power users any more, and that everything uses all of the cleverness of learn-to-rank all the time.
I suspect it has gotten even worse with learn-to-rank, as it must be incredibly difficult to intentionally under-weight the uncommon/difficult queries.
They did keep track of when users re-issued similar queries in a short period, as a signal that the ranking algorithm wasn't doing well. I think an optimal system would use learn-to-rank for the first query in a related sequence of queries, and then switch to turning some of the smarts off, and finally switching to a learn-to-rank algorithm trained only on later queries in these related query sequences. That way, they can avoid the secondary learn-to-rank instance from over-fitting the median/easy queries.