It's just an architectural decision to spawn a process per connection that Postgres made long time ago.
It's a tradeoff like most decisions.
Back in the days MySQL had huge issues with scaling to multi-core systems (maybe they fixed it now, I haven't used MySQL for a long time) while Postgres never had this problem.
When designing an application around Postgres you just have to take into account that:
1. opening a new connection is rather expensive, so you should have a connection pool
2. opening too many connections is problematic, so you should keep the size of your pool rather small and return connections back into the pool ASAP
It's just an architectural decision to spawn a process per connection that Postgres made long time ago.
It's a tradeoff like most decisions.
Back in the days MySQL had huge issues with scaling to multi-core systems (maybe they fixed it now, I haven't used MySQL for a long time) while Postgres never had this problem.
When designing an application around Postgres you just have to take into account that:
1. opening a new connection is rather expensive, so you should have a connection pool
2. opening too many connections is problematic, so you should keep the size of your pool rather small and return connections back into the pool ASAP
That's it.
It's not that hard in practice.