It’s theoretically possible to do that kind of planning on the client, but difficult and not worth it compared to letting the database do it. Especially for reporting, there’s another disadvantage: many query planners use runtime statistics from the database to build the plan; synchronizing those onto the client would be difficult and error-prone.
But why bother? If I have a thousand clients that all want to run a query, why compile the plan a thousand times (and build/distribute the local planner to all of the different clients’ platforms) when I could send a query and have the database plan and cache the query once?
For most cases I mean compiled into the client, not planned at runtime. And yes, explicitly trading away access to the live latencies and data distribution (except maybe for interactive analysts) – if you want a better query you profile and edit the client, like with any other service. Or in the JIT analogy, writing Go/Rust over JS/Java, using experience and profile-guided optimization but not realtime heuristics. Certainly this would make it easier to improve on bad plans, but that's survivorship bias, maybe I don't understand how many currently-good executions a more naive abstraction wouldn't produce.