IDs don't really solve many problems. The issues with scripts removing all your files were either caused by the absurd bash spaces and quotes rules, or by bash silently ignoring nonexistent variables. Those scripts would still need paths, since the ID of ~/.steam will be different for everyone. Scripts that need to work on more than one system, and human-authored config files, would still have paths. There are cases where you want to depend on the path, not the identity of the folder, and potentially swap the folder with something else without editing configuration.
Explorer needs to support local drives, with a lot of filesystems, including possibly third-party ones, but also network drives, FTP, WebDAV, and a bunch of other niche things. Not all of them have IDs and might not be possible to be extended. The cost is massive, solving it everywhere is impossible, and the benefit seems negligible to me (even though I fairly recently managed to eject a disk image (vhdx) in the middle of copying files onto it…)
Earlier versions of Mac OS had APIs to retrieve the IDs of directories and files relevant for things like installing applications (such as the the System directory). It effectively never used paths to identify any files; if users opened a file, they'd use the system file picker, which would provide the application a file ID, not a path.
Similarly, things like config files would be identified by their name, not their path, because the directory containing configs was a directory the system knew about. As a result, no application needed to know the path to its own config files.
This meant there was no action that the system prevented you from doing to an open file, other than actually deleting that file. There was also no way for an installer to accidentally break your system because its code didn't take your drive, file, or directory names into account.
And, of course, there are file systems that don't use paths at all, like HashFS, a bunch of modern document management systems, or the Newton's Soup.
I get your point about interoperability with existing file systems, but I think it's perfectly acceptable to offer better solutions where possible, and fall back to paths for situations where that is not possible.
Explorer needs to support local drives, with a lot of filesystems, including possibly third-party ones, but also network drives, FTP, WebDAV, and a bunch of other niche things. Not all of them have IDs and might not be possible to be extended. The cost is massive, solving it everywhere is impossible, and the benefit seems negligible to me (even though I fairly recently managed to eject a disk image (vhdx) in the middle of copying files onto it…)