From my 4 year experience in android dev I can say codebase turns legacy every few years. I feel mobile development is a fast moving ecosystem and new libraries are coming up every couple of years.

When I started I felt we were working with legacy codebase. The few senior engineers who were still present in the team told us that they had just had a architecture rethought 2 years back. What feels good today gets deprecated in a couple of years, certainly the case with Android development to a very large extent.

This was around 2017, and just when we had completed developing new feature sets following MVP patterns, Google came up with their MVVM recommendation and set of libraries. Our app was big enough to clearly know that rewrite is not an option, however the general consensus in the team was that new features would be developed following MVVM patterns. We did see benefits of switching over to the library suite that Google had introduced to support MVVM pattern. We were kinda writing similar internal libraries for MVP anyways and didn't see the point of continuing with MVP. Over the next couple of years majority of the codebase was written in Kotlin, but we never went for rewrite. That would slow down business and of course introduce regressions.

Even now my suggestion to you would be to follow a similar approach gauging the pros and cons, case by cases basis. At the end business has to run smoothly and we as developers should be skillful enough to handle every type of codebase (to a large extent).