I think this is more to do with "move fast and break things" than MVP specifically.
> Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
The interpretation I've always had is that an MVP is the smallest subset of useful features to take the product to market. How you reach that subset is entirely up to you, and in my opinion, you should take time and do a good job, not rush.
In my experience, if you solve only the problems you have, you'll be fine as far as long term maintenance goes. Hacks and corner cutting are inevitable but you'll be doing a lot less of it if you can stave off the desire to invent new abstractions.