The shockingly obsolete code of bash
blog.erratasec.com
blog.erratasec.com
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.
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).
Linus Torvalds gets this concept: https://lkml.org/lkml/2012/3/8/495
Snprintf, implemented as a library function, is also a lot (like 1000x) slower than strcpy; however, I don't condone use of strcpy.
That one has many comments and does not have a spurious fragment appended, so probably best to flag this one to try to avoid splitting the comments.
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.