Relying on this patch, you're only protected against these specific CVes, but in general a proxy can protect you from more. It's strictly additive security, right?
And if you can't or won't patch your PHP, this is strictly better than getting pwned and having your PHP-FPM execute arbitrary commands. That's as bad as it gets, and you better hope that Linux user permissions can constrain it, but your apps are basically gone. PHP-FPM even allows PHP to overwrite .php files, meaning next time they are hit, it's completely arbitrary code that persists.
As a side note: https://qbixserver.com is a project I started several months ago, that is a pure PHP server without needing nginx, and it forks after loading your classes, instead of preforking like php-fpm. It's not vulnerable to php2shell, and it is able to rewrite php code on the fly when it loads it, to make it more safe. It does things like disallowing your php scripts to write to .php files, and it makes require($filename) check that $filename actually ends in .php ... a lot of stuff like that.
The security added by this proxy is strictly additive, it can't make things worse. This proxy can be run by a Linux user with no permissions at all, so it just transforms input. Can it have a sleeper code that transforms input in a way that causes your PHP to do something even worse? Well, this is why you should point Claude at the repo and ask it if it has any backdoors. It's completely open source and GitHub actions has been used to build the binary. So I guess if you don't trust GitHub, you can also compile it yourself, but then you're trusting GCC. (Ken Thompson has an interesting talk on Trusting Trust of compilers, from 30 years ago.) But at this point we're way past what people usually are concerned about.