I think the idea, as I understand it, comes from reading some of Rob Pike's works and people who think like him. For example,

Rule 5. Data dominates. If you've chosen the right data
structures and organized things well, the algorithms will
almost always be self-evident. Data structures, not
algorithms, are central to programming.

(https://users.ece.utexas.edu/~adnan/pike.html)

I read about the analysis of Thompson NFA, in the context a simplified version implemented by Rob Pike, in the chapter that Brian Kernighan wrote for "Beautiful Code: Leading Programmers Explain How They Think". Kernighan and Pike also wrote "The Practice of Programming", where the simplified version was originally published. Perhaps I'm making too much of that example, but it's what popped into my head.

Basically I think the idea is that if you farm all the complex data structure and algorithmic code to generic libraries, you're not apt to wrestle with the core functional problems. What functional features are you willing to sacrifice, if any, to create a more elegant solution? You can't begin to approach such a question unless you're also thinking, in very fundamental terms, about how to implement and combine the data structures and algorithms. There's an interplay between how you model a problem and how you implement it that effects every aspect of your design--or should effect every aspect of it. Using an off-the-shelf implementation brings a different cost-benefit profile, including wrt to composition. Sometimes it's better to use off-the-shell code, sometimes not; but you have to be prepared to think holistically about the problem.

A language that makes it more painful to implement or apply certain approaches internally effects your calculus from the outset.

A very simplified example: say you have some problem where a stack data structure (i.e. LIFO) is the obvious solution. If you think in terms of using off-the-shelf code, then in a language like Rust you're going to use something like a Vec or w'ever. But if your language supports recursion atop a dynamically growable stack, then a recursive solution will often be the simpler and more elegant approach. Both are, fundamentally, using stack data structures. But how you implement the stack can make a world of difference; conversely, which approach you choose is highly dependent on the problem and on other aspects of the larger implementation.

Taking that process to its logical end can result in a language like Go, where they've taken one of the primary problems in expressing highly-concurrent tasks, expressing a multitude of serial flows of execution that dynamically branch and collapse (not unlike the Thompson NFA), into the core language. A dynamic, growable call stack is fundamental to their approach.[1] Now step back and realize that Go itself is a solution to the specific problem of writing network services. It's obvious to most people how Go has sacrificed certain use cases for the benefit of others. It's an elegant solution for its problem domain because of how they were willing to apply and layer their abstractions. How you implement generic data structures matters. Among other things, you can combine abstract data structures more creatively and more powerfully when you're implementing them with a particular, shared goal mind.

Another good read along these line is, "Passing a Language through the Eye of a Needle: How the embeddability of Lua impacted its design". (https://queue.acm.org/detail.cfm?id=1983083) It discusses how the semantics of the Lua language were constrained by its problem domain, on the one hand; and how they were made more powerful by novel implementation solutions (e.g. clever approach to compiling closures that resulted in elegant code with efficient runtime behavior), on the other.

[1] Whereas other languages, like Python, JavaScript, and C++ solve concurrency differently (e.g. using Promises or async/await) because they're limited in how far down they can push the implementation of the call stack.