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.

Is there any material you can recommend to gain knowledge on that topic?

Not really.

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.

Newbie code is usually not so easy to read… nondescript functions, mutations happening all over the place

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.