Is this only intended for closed deployments? Otherwise I don't see how this could be enabled on servers with unknown clients, and I think the failure modes for unsupported clients are extra bad as they'd likely see some confusing auth error? Does the <text> address this in practice if SASL2 without this is implemented? What if client doesn't support SASL2? At minimum a section for server operators would be good.

Alternatives I might suggest:
1. if unsupported by the client go ahead and "finish authentication" then send them a normal message with instructions on how to accept the new ToS? Exact instructions undefined but could be a link to a web form or clients that support this.
2. why tie to SASL at all? why not just block sending until they agree? which could be via messages or data forms or whatever, and then you don't even need client support, or for that matter even a XEP I guess... (though advice/concerns would still be good to document somewhere)

Lastly I'm a bit concerned there could be serious security/safety implications here, mitigated some if there was a way to give advance warning (hi you must agree before date X to keep using you have Y days left) but still not gone. eg a kid is away from home and gets in a bad accident and suddenly can't call for help because this locks them out. (can you tell my kids are nearing driving age? send help). At minimum another note for server operators to consider.