Reasoning behind process instead of thread based arch?

Hello!

I have a couple of final ( I hope, for your sake ) questions regarding
PostgreSQL.

I understand PostgreSQL uses processes rather than threads. I found this
statement in the archives:

"The developers agree that multiple processes provide
more benefits (mostly in stability and robustness) than costs (more
connection startup costs). The startup costs are easily overcome by
using connection pooling.
"

Please explain why it is more stable and robust? More from the above
statement:

"Also, each query can only use one processor; a single query can't be
executed in parallel across many CPUs. However, several queries running
concurrently will be spread across the available CPUs."

And it is because of the PostgreSQL process architecture that a query
can't be executed by many CPU:s right? Although I wonder if this is the
case in MySQL. It only says in their manual that each connection is a
thread.

Also, MySQL has a library for embedded aplications, the say:

"We also provide MySQL Server as an embedded multi-threaded library that
you can link into your application to get a smaller, faster,
easier-to-manage product."

Do PostgreSQL offer anything similar?

Thank you for your time.

Tim