The SQL example should probably be expanded with encoding. It is quite common to see HTML encoded strings in databases. Which is problematic if you want to present the data in a non-HTML context such as a CSV-file.
The text also doesn't explicitly about which direction the dependencies should go. Though the diagram hints at some asymmetry, I am not sure whether this is intentional. For instance I try to make my HTML oblivious to both CSS and JS. But they of course know about the structure of the HTML, to respectively present and manipulate the content.
I don't know why he's trying to turn this into some deepseated thought about "knowing your boundaries". It seems to me like his whole point is that naively templating one language with another is a bad idea (is is).
When I read the linkbait title, I implicitly thought "writing code? FIND your boundaries". Think threading is simple? Write something nontrivial with threads. Discover how outrageously hard threads are!
Point taken, I can understand the confusion based on the title. I'm referring to risk of boundaries between technologies causing people to choose the wrong tool for the job. In each example there are two ways to solve the problem. I'm simply arguing to stay native.
The text also doesn't explicitly about which direction the dependencies should go. Though the diagram hints at some asymmetry, I am not sure whether this is intentional. For instance I try to make my HTML oblivious to both CSS and JS. But they of course know about the structure of the HTML, to respectively present and manipulate the content.