A good heuristic for designing programming languages is to try to take the largest most complicated kinds of things you want to do, work them out, and then see if there is a "language lurking".
Most people make the big mistake of lovingly making small neat examples that are easy to learn -- these often don't scale at all well. E.g. "data" in the small "seems natural" but the whole idea scales terribly. And so forth for most of the favorite paradigms around today.
The problem with the idea of procedures acting on data structures is that as a system scales up, it gets more complex in terms of its data structure, and the amount of code that must operate on it, and be dependent on it. As that happens, it gets harder to change, both in terms of the structure, and the procedures that work on it. The dependencies between the structure and procedures grow in number and type. The attempt to understand it creates a cognitive load that makes it difficult and inefficient to keep track of them (if not impossible), and keep consistency in how they operate. Secondly, the amount of code that's required to operate up to spec. becomes so voluminous that it creates a cognitive load that is too much to handle, in terms of finding and fixing bugs.
Part of scaling is understanding the relationship between what is necessary to express to carry out the complete, intended model, and the number of relationships (the best I can express this is "in chunks") that we can keep track of simultaneously. Modern engineering in other fields of endeavor understands this notion of cognitive load and complexity, in terms trying to organize resources such that a constructed structure can carry out its intended function well as a result of principled organization methods.
Most people make the big mistake of lovingly making small neat examples that are easy to learn -- these often don't scale at all well. E.g. "data" in the small "seems natural" but the whole idea scales terribly. And so forth for most of the favorite paradigms around today.