"Shockingly" - hardly. It's code written years ago and has done it's job in the meanwhile.
Recklessly refactoring it is probably equally dangerous. The article says something along the lines of "changes might break old scripts, but who cares, they are relying on bugs". This is a bad attitude, the broken old scripts might become new vulnerabilities which is what you are trying to prevent to begin with.
Agreed. Everyone likes to make a sport of bashing Microsoft (no pun intended), but that is simply WHY Microsoft is so darn successful: Backwards compatibility up the ying-yang.
You buy a piece of software from 1995, it would likely have continued to work on any 32 bit Windows including Windows 7 released in 2009. The only reason why a lot of really old software has broken recently is that 16 bit support simply no longer exists on x86-64 CPUs in 64 bit mode (which can be somewhat mitigated with XP mode or Client Hyper-V in Windows 7 and 8 respectively).
Global variables aren't quite as evil as is made out, in the context of an application like a shell. It's better to think of the shell process as a big fat object instance, which gets forked when it does stuff. It's not ideal, but when the globals are appropriately scoped to translation units (i.e. static, not extern), it's usually not too bad to maintain. Each module acts a bit like a singleton.
Snprintf, implemented as a library function, is also a lot (like 1000x) slower than strcpy; however, I don't condone use of strcpy.
Exactly, well designed cli programs are themselves already a self contained object. The global variables are more like members to this instance of the program.
I don't see how it's obsolete. Just because code is old that doesn't mean that it's obsolete.
If code is sound it will be around for as long as it takes to supplant it. As far as I know the majority of the current Bash code is well suited and up to date. If this article is some kind of response to the recent vulnerability (that the media decide to lose their collective minds about) then it's simply reactionary garbage that has no real familiarity with the code base.
I'll finish by saying that a code base that is algorithmically sound will remain so for the foreseeable future.
He complains about declaration syntax, which is entirely irrelevant to code logic, and is just an artifact of how the C language has evolved over time.
Recklessly refactoring it is probably equally dangerous. The article says something along the lines of "changes might break old scripts, but who cares, they are relying on bugs". This is a bad attitude, the broken old scripts might become new vulnerabilities which is what you are trying to prevent to begin with.