How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?

Those web frameworks are lower level and have an embedded HTTP server designed to process things in parallel. It's in the standard library in golang or nodejs for example.

Sounds like one can use libuv in a CGI project and gain the same parallelization.

... and end up with something like Node.js or Vert.x.

Usually you have a thread pool (threads have startup costs too), monitor the server socket and assign incoming connections to one of the worker threads. Nonblocking architectures that do everything in a single thread also exist.

It's very common even to do this: just use Apache `mod_proxy` (or something more specialised) to forward requests to a backend server such as Apache Tomcat.

Most people don't need to worry about 'parallel' - that's the point of the OP.

Need a site to order XYZ? Unless you are a mega chain, small biz doesn't need to do anything more complex than serve its 100 customers reliably. Most 'modern' stuff is wasted abstraction for complexity which does not exist.

how many features can your process accumulate before it's called a framework?

Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.

You are right, fastcgi supports multiplexing. It seems that it's not implemented very often though.