I agree that it's unlikely a "rogue change" could get through change control processes at Yahoo, but the spec for something such as UIDONLY is supposed to be finalised before implementors deploy it, and it's clearly not based on publicly-available information. The implementation details of a particular deployment won't be made public but the standard itself must be. It's incorrect to implement a draft change if it requires action on the part of clients.
That said, as I mentioned earlier, there's nothing in the spec connecting UIDONLY with limits on number of messages so I wonder if there's some unintended side-effect, design flaw, or bug in play here. So far we have correlation but that isn't the same as causality.
I do think we should point out to Yahoo that they have implemented a function that's still in draft status and the docs say specifically not to do so.
The main message is that Yahoo need to back out whatever change is causing IMAP clients to see a maximum of 10,000 messages. This is a functional regression and unacceptable especially for those paying for and using these services in production.