I think this misses why we structure code in the first place. It's not because it's aesthetically pleasant or anyone cares about or cool usage of the visitor pattern, but because unstructured newbie code only takes you so far in the most literal sense.
There's a point, a number of lines of code, where unstructured code becomes completely unmaintainable. You can't add to it, you can't change it, you certainly can't understand it. It's just what it is.
Structure, modeling, software architecture, testing, development practices, those sorts of things, these are basically the entrance fee for getting to work on larger problems.
While I agree unstructured code is unscalable after a certain point, I personally don’t find newbie code hard to add to, change, or understand. It’s still straightforward, that being a two-edged sword, in that it simply lacks abstractions that would improve a maintainer’s productivity.
It becomes difficult to work with as it grows. Like it tends to almost implode at a certain point.
I think it's a repeating pattern. A lot of people with experience writing code but inexperience with software architecture (which is arguably most professional developers) tend to create quite a mess if you task them with designing an application.
Architecture experience is a lot harder to gain as you really only get a few shots to practice the craft, and there's a lot of beginner experts giving some seriously questionable advice if you go online looking for a second opinion.
What's written down tends to age poorly and become prescriptive, that's beyond the fact that a lot of supposed architectural advice is written in bad faith as marketing for cloud- or consulting services.
I think a big part of the problem is that it's all very situational. The same architecture choices may be fantastic in one project and a chronic migraine in another.
In many real-world apps, convention is far more important to the ability to add or change code than whether you write in some naive or mature style. That convention may be flawed, and even then you'd need a good reason to fight against it. It's also notable that convention almost certainly means structure and abstraction.
Sometimes I look at a codebase and I barely need to look around to feel at home. How do you grok a codebase while barely looking at it? Convention.
Unstructured code blooms into a rats nest of if/else statements with complex flags calling into other functions. There ultimately becomes no good way to avoid regressions and no way to make guarantees about what can be added in the current "architecture". Working with people that splat this code is not necessarily bad as long as you are allowed to refactor it when the time comes.
My first microcomputer ran a BASIC. The variables in that BASIC were single letters like A, F, X, etc. or a single letter plus a single digit like A4, A7, G2, etc.
Coming back to a program that I had written several months previously was pointless, as I couldn't remember what all the variables were for, or what they did. It was just easier to completely rewrite a program, rather than maintain one.
My next language happened to be COBOL with its variables that could be given fully descriptive names like EMPLOYEE-HOURS-WORKED, ITERATION-COUNT, SALES-TAX-VALUE, etc. Variable names like that mean that I can look at programs that I wrote in the 1980s and immediately be able to maintain them. That habit of giving variables really descriptive names has remained with me for decades.
There's a point, a number of lines of code, where unstructured code becomes completely unmaintainable. You can't add to it, you can't change it, you certainly can't understand it. It's just what it is.
Structure, modeling, software architecture, testing, development practices, those sorts of things, these are basically the entrance fee for getting to work on larger problems.