> What's so new about any of Wirth's languages, even Oberon?

You've been given the answer already: Simplicity. You keep ignoring it.

Both of implementation (which can be met by e.g. Smalltalk, Lisp, Scheme, Forth as well), and of usability (which some might argue the former could, but the reality is most people have gravitated towards languages closer to the ALGOL family for usability).

And yes, it's "tweaks" on ALGOL, but those tweaks mattered, in terms of simplifying implementation. ALGOL users expected gc (though it was not technicall required), Pascal users didn't (though it wasn't forbidden). ALGOL's added complexity around type checking of variants mattered. ALGOL's file IO was bizarre (giving me horrible flashbacks to Simula's equally broken IO), and ALGOL 68's definition of formatted IO took up several dozen pages of the spec... ALGOL supported user defined precedence rules for operators, which, while it's not hard to implement is significant added complicity vs. a typical hardcoded recursive descent parser for Pascal, Modula-2 or Oberon.

Having used Simula (it was compulsory for CS classes at my university way back), the OOP in Simula is really quite different and at a far higher complexity level than Oberon.

Another comment listed influence directly on languages. But the influence on languages is far broader in terms of the simplicity of the languages being a facilitator for an explosion in language designs. It was seeing the ENBF for Pascal that got me to start experimenting with parsers and compilers, for example, because the simplicity made it clear that it was possible for a hobbyist to create their own from scratch. The existence of simple Wirth-language compilers made experimentation easy - I spent too much of my teen years looking at compiler source, and the Pascal compilers were easy to understand and modify. I wrote my first expression parser in Pascal, and my first code generator, and soon I ended up bootstrapping my own Pascal-inspired language.

Simplicity matters.

It's easy to forget that now when we have decades of hardware progress and orders of magnitude more RAM and CPU to work with, and decades of additional books and resources on how to build compilers using methods that were computationally infeasible at the time.

The existence of very simple compilers and languages has also been part and parcel of a lot of work at ETHZ that is not part of the Wirth languages themselves, but that was enabled by having access to simple languages as a foundation. Personal favourites of mine is work such as Franz' work on Semantic Dictionary Encoding, which led to his work on JVM JIT's etc.. Franz' student Andreas Gal came up with trace trees [1]. Brandis did fantastic work on showing a wide range of optimisations could be added to Oberon at a fraction of the complexity of the similar optimisations in gcc at the time. Mossenbock and Brandis did excellent work on SSA generation. Franz did simple but excellent work on protocol extension (dynamically propagating method overrides at runtime; I used parts of that in my experimental/unfinished Ruby compiler). There were many more. Some undoubtedly would have happened with more complex compilers to work on as well, but if you read the reports and dissertations from that period at ETHZ you also see plainly the influence that Wirth's approach carried over in the students subsequent approaches and focus on simplicity.

> a hypothetical "Turbo Algol" have been much different than "Turbo Pascal"?

It would have been slower and too big, and so lost a significant part of what made Turbo Pascal important.

In terms of implementation being more important, the speed etc. of Turbo Pascal depended heavily on the simplicity of compilation. Being able to keep the source, the compiler, the editor and the compiled object code in memory at once was a big deal facilitated by the extreme simplicity of the language.

[1] "Incremental Dynamic Code Generation with Trace Trees", Andreas Gal, Michael Franz, 2006: https://static.aminer.org/pdf/PDF/000/286/022/profile_driven...