But here you have garbage in = non-numerical return value from a function that is supposed to return a number albeit in string form. If this function is just being used to display a number to the end user, which is pretty typical use, then the result is going to be garbage in = a number somewhere isn't displayed properly to the user so they need to notice this and report the bug.
If garbage in = throw an error then whilst the user would see an error this is much more easily detected by the code itself and gracefully handled whilst notifying the developer of the problem. The developer will also be able to see where the problem is and be able to trace it back through the code from the input to the number_format call backwards, rather than having to worry about any code after that function call and trying to work out exactly what the user did in order to trigger this weird result in the first place. By having an error with a good error message they get an exact starting point for their investigation.
PHP is riddled with functions that instead of doing the right thing try to guess at what they should be outputting, leading to a huge number of hard to detect bugs, erroneous behaviour, and ultimately fragile programs. This particular call merely highlights one such function, and it looks like the core devs simply do not understand the innate issues with their chosen approach.
To bring this back to the topic of the article itself - a huge amount could be done to improve PHP by forking the project and redesigning the core library to be safe and consistent, removing all the broken functions that have been retained for backwards compatibility, and simplifying the library as a whole.