YAGNI means things get done when they need to get done and not before. It doesn't mean they never get done, not unless they are never needed. It means you only do what gives the customer immediate business value. What immediate business value means is subjective to every customer and every project.
In either case, you can't lose anything with YAGNI.
In the other case, you lose time writing code that never gets used, and writing tests for code that never gets used, and writing documentation for code that never gets used, and maintenance on code that never gets used, people wondering what this code does, and if it ever gets used, ad nauseum.
Example
If I am working on a prototype/proof of concept or 1.0 version of an application then I don't need a design to scale to level of Facebook. Hell I don't need a design to scale to the level of Facebook, until I start seeing that I have that kind of traffic.
Do you think Zuckerberg designed the very first version of Facebook to scale to 500 Million users? No, he designed and built it to do just want it needed to do and no more. If he had tried to waterfall the design for 500 Million users from day one, Facebook probably would have never been released period.
The practical way to do things is how he did it. He started out with PHP and MySQL, and the redesigned and rewrote as needed based on business value, scaling to millions of users was of tremendous business value, but not at day 0. At day 0 just launching something was the tremendous business value.
He planned on redesigning and rewriting. Which is a different mindset than planning for the kitchen sink and never actually developing or delivering anything useful that is complete.
Planning on end of life for a code base, and rewrites is Agile and future proof. Trying to come up with some undefined goal of "flexible" just ends in failure every time. You are designing without any need and wasting time you could be developing what is of business value instead of wishful dreaming about features that will never be used.