> Posix shell is a programming language where the only type is a string.
You got it!
> Text as an interchange format works reasonably well in practice for a wide range of tasks.
Solutions using real programming languages score better on almost every conceivable metric (robustness, tooling, debuggability, maintainability, extensibility, performance, library ecosystem, developer pool, language pitfalls) other than initial time-to-develop, where they only win by a small margin (e.g. 10 minutes to develop a script instead of 2) - so, unless you're developing software purely for your own enjoyment, it's somewhat irresponsible to use shell instead of Python (or some other real, but script-amenable, programming language).
> To me shell, easy to combine unix commands and text as interchange is a clear example of New Jersey style from "Worse is better" [1] and their critique comes mostly from followers of MIT/Stanford style.
The New Jersey style is not only flawed on a theoretical level (just go look at any of those characteristics - tell me that it's more important for your bank or X-ray machine software, or your compiler or firewall to be simple than correct - and it's pretty clear that software that prioritizes simplicity above all else doesn't actually usefully serve humans, which is the point of software in the first place) but also unpopular on a practical level for actually building useful pieces of software.
The New Jersey style is a style guide that is only useful for making art projects (where the value is in beauty, not utility) that aren't required to be performant, maintainable, feature-complete, or have correct behavior.
> all my scripts worked reliably enough and didn't suffer from any significant bugs so why bother
Because of the above list of metrics that real languages score better than shell on - the only thing that shell wins on is initial time-to-development! It's going to be harder for others to maintain, debug, optimize, understand, and extend your scripts after you leave, harder to diagnose bugs, harder to find people who can write bash...
> shell have its niche
Yes - but it's an extremely narrow one where time-to-development is the most important metric and you're only working with small problems (as above a relatively low problem complexity, shell scripting is slower than using real languages anyway) - and these conditions are very rarely true at the same time (e.g. in infrastructure you might have a small problem, but correctness is far more important than TTS - while in a startup you want low TTS, but your problems are non-trivial).