Activities are responsible for handling a window, the life-cycle and other things. They must have some controller in them but they don't have to have view layer objects. They can have a view layer interact with its own XML and any class can subscribe to their messages with Interfaces/Listeners. You get to decide which ones. That's the major point that keeps getting stuff 'added onto.'
It is most beneficial to make a controller/presenter and a view for each Activity or fragment using composition if you want the most decoupling (that is you want strict MVC because an Activity/Fragment can be everything in one). If you want to treat the activity as a controller/presenter that's fine but note its not the strictest MVC. I think you refer to this as a 3 layer architecture.
The important thing is MVX is just an example of decoupling a common problem or pattern it's not really an architecture and it's not really a set standard either. Unfortunately, everyone has a different opinion on what it is. What is important is you understand the principle behind it. That is; a controller doesn't know about the view. A view doesn't know about interpretation of anything. When you do it your view is so dumb that it shouldn't be tested.
Also, chances are if your view is the Activity you might not understand the problem MVC is trying to address or you do but don't realize the ways to decouple them in Android. You might think it is a bad idea because like most frameworks they are built on telling you to couple your application and logic to it. They design things specific to keeping that coupling. Now your app has to change with the framework.
I don't see much of people 'adapting the framework,' where are these adapted frameworks? My best guess is you are confused. The difference I think you are thinking of is letting the framework make all your design choices. If you put your application and business logic in activity and mix the dependencies then you have coupling to a specific framework to code that has not anything to do with that framework.
You should start looking at dependencies not what relies inside of what. People who do not understand clean architecture could easily become confused when looking at the code. It does't look like the code the framework writes. In short the framework wants you to couple to it. However, a good framework is not so restrictive that you must do it.
Please see a link below for some context: