Is it? My reading of the article is that gcc gfortran expects the length argument for CHARACTER* 1 to be provided as usual, but there is a lot of C code that does not provide that when calling Fortran functions.
And this outcome is in fact nothing special to C and Fortran. I can just as well write a shell script (or any other) which "expects" that there is a parameter and if I don't use it and I later start to depend on it I'm sure there will be some other scripts calling that one and passing something else than what was "defined" as expected to be passed.
On that topic, erverybody should read ryl00's comment here. Having more than one really different target is the only practically effective path to immunize from these kinds of dependencies. For me, it's one of good arguments against the "monoculture" software targets.
The actual problem however is that it still works in simple cases --- when the Fortran code doesn't access the string length (and apparently, doesn't do tail-calls) --- even when the extra integer length arguments are omitted from the call. Because of this it was possible for the mistake to spread widely...
Fortran compilers can set their own ABI and usually do for everything after Fortran 77. For Fortran 77 and earlier, which includes CHARACTER* 1, most compilers use the same ABI that the Bell Labs f77 preprocessor used, which lives on as f2c in the modern era. This compatbility is common enough that many packages written in C that want to be called from Fortran have this ABI directly embedded in their source code.
The problem is that the current gcc gfortran front-end doesn't do this for CHARACTER* 1 strings, and there's C code expecting that extra string length argument. And if they want to change it, any object code with CHARACTER* 1 arguments in it needs to be recompiled.