That would break so many things that it would be insane to do.
You could just run nginx as a separate user with very limited rights, or just run it on Docker. This, plus updating regularly usually fixes 90% of security issues.
Most (I hope all) distributions already run nginx as a separate user. It's best practice.
But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).
If that's an option then that's the right way to go. There is a reason some MTAs have been doing something like this for decades now (I'm thinking of qmail).
To be honest, I'm not sure if it's even possible to run the application/interpreter/cgi (e.g. php) as a child of the nginx process - though with Apache I'm still seeing that occasionally.
But that won't help if you alias to "/foo/bar/www" and the the application has a SQLite database at "/foo/bar/db.db", which the nginx user has to have access to. Same if you run it in a container (or lock down permissions using systemd).