Well, I haven't said it has to be single-threaded like pgbouncer. I don't see why the bgworker could not use multiple threads internally (of course, it'd need to be not to mess the stuff that is not thread-safe).
Certainly architecture with N multiple scheduling bgworkers and M executors (backends) may be more flexible than solution when scheduling is done in executor itself. But we will have to pay extra cost for redirection. I am not sure that finally it will allow to reach better performance. More flexible solution in many cases doesn't mean more efficient solution.
I think you can take the best of both worlds.
You can take your approach of passing around fds, and build a "load balancing protocol" in a bgworker.
The postmaster sends the socket to the bgworker, the bgworker waits for a command as pgbouncer does, but instead of proxying everything, when commands arrive, it passes the socket to a backend to handle.
That way, the bgworker can do what pgbouncer does, handle different pooling modes, match backends to databases, etc, but it doesn't have to proxy all data, it just delegates handling of a command to a backend, and forgets about that socket.