The main purpose of the MVP is to learn and understand better the solution space. After the learning was done the MVP was retired and the proper product was built instead. Why was this important? Because of the word "minimal". A proper MVP that was built for learning never included vital security, scaling, accessibility or privacy considerations. That was fine if the MVP was retired after serving its purpose.
However, not everyone understood this vital limitation of the MVP. Startups usually have money and time just for that one MVP. If it's "successful" - startups will keep adding to it in a desperate attempt to stay afloat. If that works - they will keep building "MVPs" until they grow and realise they now need a huge refactoring, or more often, total rebuilding of their products.
But that's startups, for them, it really is the thinnest line between survival and failure. Unfortunately, not only startups now misuse the MVP concept. For many established companies, MVP became synonymous with the first version of a product. Business leaders, frustrated by long software development cycles, took the MVP as an opportunity to demand faster delivery from their teams.
The result? Products that have technical and design debt from day zero. Products that lack compliance, are full of security holes, don't scale and don't perform. And the teams that build them are often being blamed, even though it is not a fault of theirs.
The solution? Quite simply - honesty. Be honest about what you are building and why. If that's an MVP - you must throw away the code afterwards and start anew with all the learnings MVP provided. If you plan to use "MVP" code further, then just call it version one and don't mislead your team. That way you'll avoid many frustrations and time waste going forward.