> If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?

The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.

I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.

Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.

If your using a versioned codebase you likely don't want that anyway. Otherwise you'll have untested code on production, and you'll have to commit it to the project repository from production.

Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.

It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.