(1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning (there are a small number of POSIX systems which implemented it, e.g. SCO OpenServer's HTFS, but for whatever reason more mainstream systems like Linux or *BSD never did)
(2) Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink()
(3) The simplicity of the interface between the shell and the commands it runs (just a list of strings, only slightly better than the DOS/Windows approach of a single string), and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself.
Regarding (3), OpenVMS DCL, IBM OS/400 and Microsoft PowerShell are all examples of systems where option parsing/etc happens in the shell, and the command is passed a parsed command line structure instead. However, although they are better in this regard, they have other disadvantages (the first two are super-proprietary; PowerShell is open source, but weighed down by the heaviness of .Net)
I think a lot of historical issues with Unix are due to the fact that shared libraries didn't exist until much later, so seemingly obvious things like "put wildcard parsing in a shared library like getopt() is" weren't possible at the start. Also, Unix has never had any kind of standard structured data format (JSON would work, but it didn't exist for the first 30 years of Unix's existence), which is a problem for ideas like passing command arguments as structured data.
> But then the terminal/TTY situation has barely changed,
POSIX TTYs are a horrific pile of kludges, especially when one considers stuff like ECMA-48 (which isn't technically part of the POSIX TTY stack, but de facto is). Someone should just redo it as something more sensible, like exchanging null-terminated JSON packets. But getting everyone to agree on that is probably too hard.