Specifically, I've seen pg take a query that looks like this:
select ... from a join b join c join (select ...) d
select ... from (select ...) d join a join b join c
With the lack of hints, almost the only tool you have to control query plans effectively in postgres is parenthesized joins. Since it's more liable to rewrite the query, the language ends up being less imperative, and thus less predictable. And I like predictability in production.
SQL-level feature set is no comparison of course, pg wins easily.
I'd also suggest disabling nest_loop_entirely if you are having problems with bad cardinality estimates resulting in nestloop plans that run 100 times when the planner estimated once.
It is interesting to see how postgresql will often choose hashmap scan, even with very up to date statistics and much better paths available.
SQLServer's planner does an amazing job of digging right into joins/sub-selects to constrain preliminary results for joins.
It's a very hard job and MS and Oracle obviously have had some of the best people on the world paid well to work on this.