The command line of the processes has always been considered public information in Unix and was always available via the
ps(1) command. The environment of a process, on the contrary, was never such public information.
In the original Unix implementation,
ps was a setuid executable which was opening
/dev/mem and extracting all the information directly from the live memory of the kernel, in the manner of a debugger. Linux supported a plan9-alike
/proc filesystem since early on, and
ps was implemented as a simple non-setuid program which was just opening and reading files like
/proc/<pid>/cmdline. Since those were meant both as the regular kernel/user interface for obtaining that info, and as a shell-friendly alternative to parsing the output of
ps (yuck), they could not be and it made no sense to be more restrictive than
Sure, it would affect other users running
htop and the like - but that's a good thing, right? That would be the point of not making it world-readable.
No it's not a good thing. Besides breaking the standard (see the link above) that will make the system un-debuggable without root privileges, and the security advantages of that would be at best illusory. (Notice that at the time where Unix was invented, security through obscurity and free speech restrictions weren't yet as fashionable as they are today.)
You don't have to imagine what such a Linux system would look like -- there's already Android which a non-rooted system is a nasty black box (locked down in all possible ways, not just with
hidepid) for its actual user(s), yet in no way more robust against external attackers and data collectors than a typical Debian or Slackware desktop or server.