A simple example would be something like predicate pushdown:
with mycte as (
select a, count(b)
from foo
group by a
)
select *
from mycte
where a = 10;
There is enough information in the statement to plan it as with mycte as (
select a, count(b)
from foo
where a = 10;
group by a
)
select *
from mycte;
Before, Postgres would have computed the aggregate for all values of `a`.
On the other hand, if the same query were written with subqueries instead of with CTEs, then the query optimizer would not treat it as an optimization fence. If it could utilize indexes or rewrite the query to be relationally equivalent, it would do so.
Note that sometimes that optimization fence is beneficial. There are situations where it's better to create temp tables and run smaller simpler queries instead of running an extremely complex monolithic query because the query planner isn't perfect even with hints. You can still enable that optimization fence functionality in PostgreSQL if you need to, but it's generally pretty rare that it happens like this. Still, you'll see stored procedures for reports still using temp tables and even cursors sometimes because they can be made to perform better in certain situations.