It's often difficult to talk about hypothetical situations and talk about them being problematic without hard numbers. There are so many different factors to consider here. Mainly, we don't have any idea what kind of response time is required. For example, you could have a query that responds very quickly but the results take a second each to process. In such a situation, optimizing around the initial query is rather pointless as producing more than one result per second will have no impact on the overall runtime of the process. This is somewhat overly simplistic but you get the idea. How long does it take to retrieve the users? Unknown. How long does it take to retrieve their orders? Unknown. How long would it take to retrieve the same information from a relational DB? Unknown. There are too many unknowns to have a specific answer.
Also, it's a much different question to ask what you do if you are actually in this situation or if you are trying to decide whether microservices are a good idea. I get the idea that this is more of the latter or maybe you are just pondering about this abstractly.
Microservices are not magical fairy dust that makes everything better easier and faster. On a technical level, they create a number of challenges such as this. They also have advantages. Most of the advantages are non-technical. In large corporations, trying to manage one giant database for all the teams in the company is infeasible. All the coordination and testing required to do that properly will add months to delivering changes. Microservices allow teams to manage their own DB, use the tools that suit them and create clear boundaries for how other teams interact with their systems. In other words, one of the most significant advantages is organizational and has almost nothing to do with creating the most optimal technical solution.
A much less common reason for using microservices is a monolithic relational DB scales vertically. As the scope of the data and the number of clients increases, the costs rise at an increasing rate and at some point, the maximum capacity of the DB technology can be exceeded. Microservices, (and nonSQL DBs) are much easier to scale horizontally.
The point here is that if you are going down the microservices road without one of theses issues or some other reason that forces you to do that, you are probably creating more problems than you are solving. There are many teams that went with a microservices strategy because that's what the cool kids were doing and now have a mess on their hands.
Now if you are in a situation where you have this kind of design and you know that the basic solution (the approach you describe in section PS1) isn't going to work, there are a few things you can do. The most performant is likely to be adding extra data (user name, in this case) to the orders DB. Of course, this takes development time and you'd need to know what the queries are ahead of time. This also has a storage cost as well. You could also create standalone indexes (perhaps as another microservice) that allow you to get to the orders you need more quickly. Another option is to use horizontal scaling process the query in parallel against multiple DBs. This is not an exhaustive list but should give you some ideas around possible approaches.
