My point is, a publicly facing web application should not have permissions to update it's own code. The possibility of the application being compromised and then having the application modified to support further system compromise it too great.

Well, that's how WP works so we're stuck with it. On the plus side, it makes for a great plugin experience for non-technical users.

Having done WP installs where the only web-user writable area was for uploads (and that is configured to not execute anything), I will have to dispute your assertion. The fact that the vast majority of WP sites are web-user writable is just inertia and/or bad security practices.

You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.

Yes, you can do that, but you're fighting the way it is designed.

You mentioned the uploads directory, but there are very common plugins that need write access to other files. Almost every caching plugin for wordpress, as one example.

You also have to replicate the functionality to do upgrades for plugins, themes, and core WP, including ones that need database upgrades.

It's just a risk management decision. In my case, all the hoops to make the filesystem read-only aren't worth it. Retaining the built-in upgrade functionality is of higher value. We have offsite backups and file integrity scanning, and will fall back if needed. If the sites were, say, e-commerce sites, I would have made a different decision.

Upgrades can be a single "composer update" and then committing the composer.lock file. Mine are a bit more as I review changes between versions as well. I am very careful about what plugins I use for this very reason honestly. If it's not well-behaved enough and requires the ability to write outside of uploads then it's not used.