This is a novel approach to designing a programming language that, I believe, came along with C. Older languages, like, for example, PL/I, tended to put much of the standard functionality in the language itself; C, C++, Haskell, etc., on the other hand, decided to externalize everything except for the "core" facilities; the benefit of this is of course that a developer can now, theoretically, use the language to implement anything, but that comes at the expense of the language being conceptually more complex. (Even a simple language like C is considered complex by many due to its excessive reliance on the use of pointers and the manual memory management.)

and disadvantages being it will be never as clean, as easily optimizable or debuggable, as the one implemented in language.

UFCS is better than C++ ranges. builtin sum types are better than std::variant, etc..

Every user-level feature that you cannot implement about equally well in a library as in the core language betrays a weakness in your core language.

All languages have weaknesses, and so end up with core features. Sometimes the language evolves to the point where the core feature is not needed anymore because a library does equally well, or sometimes better. A good example is the C++ Standard Library std::array, which is better than a built-in C-style array in every way except being a little longer to type.

Something that showed up in 1972 cannot still be called "novel" 50 years later.

There is nothing ironic about a language that provides unlimited power, including the ability to restrict the power of things built with it. That is the whole point of language design. At least, languages meant for professionals.

Many languages have strictly limited power, in order to keep non-professionals from getting into trouble.