You're technically correct, but you're really underplaying how goddam troublesome it can be.
Just a couple days ago, I tried to add a tool to my PATH and it wouldn't stick because both Intel and Microsoft decided that their utility needed not only both Program Files and Program Files (x86) for each (doubling their PATH usage), but Intel also decided to arbitrarily use positively uselessly long directory names. As in, I actually think it's plausible Intel specifically did it to screw over PATH usage.
Infuriatingly, the hard PATH limit is after any environment variables have been expanded, meaning there's no reasonable way to compress the path down. (Never mind that it also only expands variables less than the string 'PATH'.) In the end, I used DIR to find what the 8dot3 representation of each repeated or long directory was.
Now I have enough free characters, but no fracking idea exactly where they point. It's the sort of crazy that I really thought would have been lic'd by now.
Edit: I forgot to note that the hard limit is a truncation. So while you can happily add to the PATH variable in the (now out-dated) dialog, the actual console won't see all of it. I had moved folders around before my rant above such that my final PATH exactly ended on "\node\bin". It's sort of a weird game of PATH golf at this point for me.
Did you take a look at those Intel binaries they wanted on the PATH? They are all diagnostics tools that so far as I know aren't very useful to the average developer, much less the average consumer. There really doesn't seem to be a reason for Intel to add them to the PATH, because how often do people make support calls directly to Intel?
I just remove the Intel folders from my PATH (every time one of their drivers resmashes them into the PATH).
IIRC, it's more a problem with Microsoft making that there preferred way to make programs available in the shell rather than having a well-known user and system level locations places to which symlinks could be placed.
The preferred way is App Paths [1], it's just that there's not really a good UI for that and most people are used to Unix-style PATH environment variables so a lot of software depends on that that maybe doesn't actually need to and a lot of installers are built for that because the person building the installer didn't find the App Path tools but did find the Environment Variable smasher.
Also the fact that for compatibility reasons the CMD shell doesn't do App Path-based lookups, but in some ways that is an implementation detail (and what "start.exe" and its PS equivalent are for), and something that only really impacts shell-using developers.
That's more a problem with those programs than anything about the length of an environment variable.