Preparing for "everything" is kind of impossible. Preparing for most of the things takes too much extra time, and most of the time YAGNI :) . The real problem IMHO is when the solution for upcoming problems is hacked into the simple code, when a clean solution would need mass refactor.
The solution created today is for the current requirements, so when new requirements come which alter for example architecture, it will be hacked in, cause true refactor is impossible. Gates need to be left in the original solution for possible extension/changes.
Gates must be left in the code (for example coding for interfaces, impl can change), but i think those aren't against YAGNI. If a change is so big that it actually needs architecture change, that will be hacked anyway, YAGNI or not, and with hacking most likely the continuous quality is lost.