How about ALTER SYSTEM is disabled if the file postgresql.auto.conf.disabled exists? This is somewhat similar to making the file read-only, but doesn't risk other tools breaking when they encounter such a file. And it's more obvious and self-explaining.
A separate configuration file would be self-documenting and able to always exist; the same properties as postgres.conf
ISTM the main requirement regardless of how the file system API is designed - assuming there is a filesystem API - is that the running postgres process be unable to write to the file. It seems immaterial how the OS admin accomplishes that goal.
The command line argument method seems appealing but it seems harder in that case to ensure that the postgres process be disallowed from modifyIng whatever file defines what should be run.
One concern with a file configuration is that if we require it to be present in the data directory that goes somewhat against the design of allowing configuration files to be placed anywhere by changing the config_file guc.
Any design should factor in the almost immediate need to be extended to prevent copy variants that touch the local filesystem or shell directly.
I was pondering a directory in pgdata where you could add *.disabled files indicating which features to disable. This is a bit more pluggable than a single configuration file but the later still seems better to me.