I'm pretty sure the original rule recognizes no exceptions, and certainly not on something so broad as an entire category. It may be that much narrower exceptions could exist, but future-proofing sounds like it could simply be justified as a feature actually needed now, if not just good overall coding practice [1].

The danger of allowing such a broad exception is that it doesn't take a huge leap to imagine a situation where it's used as permission to do something like a custom implementation of ACID in the app backed by a NoSQL key-value store (or "sharded" MySQL, before NoSQL was a thing).

[1] YAGNI isn't a standalone rule but one of many in the "XP" collection. Any one of them, out of context, in complete isolation, could just as (if not more) easily require a long list of caveats/exceptions to make sense in the general case.

Yeah, although there is a difference between planning for a specific future which may not arrive, and planning to make any future change less painful.