Higher level languages often have opportunities for additional optimisation over the straightforward implementation in the target language. This is because the semantics of the high-level language offer guarantees that the target doesn't, or because the intent is more clearly preserved in the source language.
Whether or not this is true for PQL/SQL, I don't know enough to say. But I do know that I don't write SQL at a high-enough level to be sure that a wrapper couldn't compile to something more efficient than what I produce, especially for complicated queries.
When dealing with SQL, these higher level languages (which are converted to sql, such as FetchXML and Pql) are traditionally quite limited by what use cases they are suitable for. They are not suitable for complex joins and grouping particularly across large tables and resultsets for example. Not particularly suitable for joining remote data sources particularly of large result sets.
They are suitable for Reads on tables that are tuned specifically for the desired use cases. The amount of optimization required in the conversion should be limited intrinsicly by this assumption and the higher level language should be strict enough that an optimization related to deciding A/B SQL Approach in the conversion to SQL is not required (because results will be unpredictable due to table sizes etc)
SQL also has a lot of edge cases where, because half the syntax got bolted on after the language was initially finalized, a conceptually simple request can turn into a multi-level mess of a query.
Whether or not this is true for PQL/SQL, I don't know enough to say. But I do know that I don't write SQL at a high-enough level to be sure that a wrapper couldn't compile to something more efficient than what I produce, especially for complicated queries.