> What are the legitimate use cases to not treat /proc as readonly,

Only some parts of proc are "read only." /proc/sys is filled with writable controls.

> my first impulse is "Why do we allow this?"

The user is allowed to do whatever they like with their machine. It's the reason I use linux. It never puts me in a position where "system policies" or other default "security theater" nonsense disadvantages me on my own hardware.

If you're that concerned you can easily add a policy framework, like SELinux, or others, which would prevent this from happening or raise an exception if it does.

> that seemingly doesn't have any legitimate use case on a server.

There are dozens of other ways to achieve this same effect that rely on mechanisms that have legitimate use cases. In particular if you are root you will not struggle to find ways to hide processes. In this case you can just observe "/proc/mounts" to see that something perfidious is occurring.

> I can still nuke and rebuild it in an hour or so.

As long as there is no important data at rest within the server. This isn't always the case.