First of all: The server must not reply with 250 OK but with 221 OK to a QUIT command.
But I think you misunderstood what the OK stands for here, the SMTP standard (without extensions) doesn't care about what comes after the status code, it was a dumb standard and during its implementation every mail server was an open relay. You can reply with 221 Have a nice day and it's still compliant with RFC 5321.
Also, RFC 5321 does replace and incorporate a lot of the older stuff (see the descriptions).
The important part for you is this:
This document is a specification of the basic protocol for Internet
electronic mail transport. It consolidates, updates, and clarifies
several previous documents, making all or parts of most of them
obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about
particular extensions.
In your example, as far as RFC 5321 is concerned, 221 is the status code and everything beyond that is just text. I think it becomes more clear if you read the termination section of RFC5321:
https://www.rfc-editor.org/rfc/rfc5321#section-3.8
So TL;DR: 221 2.0.0 Goodbye is perfectly valid for RFC 5321.
Keep in mind, that "extensions" are called that for a reason, they are built on top of the base standard. Rather than replacing, they provide an addition to it.
But don't sweat it, SMTP (and email in general) is a Frankenstein monster, the only reason it wasn't replaced entirely is the wide usage. Providing this kind of backward compatibility for a standard that is in essence over 30 years old is just ridiculous in the 21st century.
And to give you even more peace of mind:
2.2.3. Special Issues with Extensions
Extensions that change fairly basic properties of SMTP operation are permitted. The text in other sections of this document must be understood in that context. In particular, extensions can change the minimum limits specified in Section 4.5.3, can change the ASCII character set requirement as mentioned above, or can introduce some optional modes of message handling.
In particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host. If this strategy is employed, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day).
https://www.rfc-editor.org/rfc/rfc5321#section-2.2.3
