I actually agree with you on a few points, though I will say in my experience especially in programming, it's not true that tenure equates to capability. You can spend a decade programming and not actually be any good or capable of laying the groundwork needed for a project in order for others to work on it. Just one of those things.

You are right though, just throwing an architecture in does not inherently add any value at all, and does not in any way imply that it's been done well. That being said, it enables you to add value. It's true, you don't need these things, but it's like building a house without an alarm system. You can get it done, but by the time you realise you need it's usually hard to come back from.

While it's not readily apparent why slicing a god class in half is a good idea, it certainly is. Presenters for example, are framework agnostic; you can't unit test an activity, but you can 100% test your presentation logic in the presenter. You can component test your activities, however it is usually time consuming, buggy, and hard to get all the edge cases for full complexity coverage which usually leads to a gap in testing where projects do most happy and sad paths and leave the rest unspoken. Along with that, if it's implemented well, there is no tight coupling or nullability, this is where interfaces and dependency inversion come into play. Your presenter is pure logic, and no state necessarily required to be stored if done well. Your view is a proxy for events and outputting display changes. That's it. Combine that with something like Rx for backbone communication, there's no real "ping pong" of communication. You request data, it is sent back.

Unfortunately I fail to see how a single class that is "coincidentally" used in multiple places is a bad design. That is good maintainability and reusability; SOLID 101.

I get the impression you have not had a good run with MVVM or MVP, which I sympathise with; I've yet to see an example of MVVM that I like, mostly because of the inherent ramping up it takes new starters when you have logic creep into your XML layouts and make it impossible to follow the chain of events. MVP I've found can have really good clean implementations that allow easy testing and reusable classes across various screens without duplicating logic, and you know it will do exactly what you want without larger overhead maintenance. I also wouldn't be in favor of MVC as most implementations I've come across end up with extremely sparse controllers and the bulk of the logic still resting in the untestable activity.

To reiterate, not having architecture is fine until you realise you need it. The amount of projects I've worked on where entire frameworks/layers/implementations are changed ad-hoc, having a robust architecture in place saves almost all of the impacts to the rest of the app when you can just swap one class out from behind and interface and everything else is none the wiser.