"Orders with customer names" used to be one JOIN. Once orders and customers are separate services with separate databases, what are the actual options for that query, and why isn't "let orders read the customers table directly" one of them?

A service owns its data and nobody else reads its tables — the moment a second service reads customers directly, that schema becomes an interface nobody declared, and a column rename or a new index added for one service's workload can break or slow the other at any time, with neither team able to deploy independently anymore. The real options are all more work than a JOIN: the order service holds its own copy of the customer's name, kept current by consuming the customer service's events; the caller composes the two services' APIs at read time; or a read model is built from both services' events specifically to answer this kind of cross-entity query.