From XEP-0001, regarding Final XEPs, "limited modifications may be made as long as
they are optional, backwards-compatible extensions rather than modifications to the core
protocol itself."
XEP-0030 requires that entities return "one or more <identity/> elements and
one or more <feature/> elements", so the otherwise redundant
'disco#info' feature ensures this will always be the case, even in the (seemingly
unlikely) situation where an entity somehow supports disco#info without supporting any
additional features. So, is removing the requirement for this feature an optional,
backwards-compatible extension?
An obvious, and maybe more realistic, retort is "but will it break anything?"
So, would it cause problems for implementations if they were to receive a reply containing
zero features (since they were originally implemented expecting there will always be at
least one)? Equally, would implementations have problems calculating the caps hash
(XEP-0115) with zero features (the algorithm doesn't explicitly account for this)?
It's also worth considering whether leaving it as-is causes harm. It's nice
(desirable, even) to clean things and remove 'warts' like this, and there are
likely many more scattered throughout the protocol, so it's worth noting for XMPP 2.0,
but this has been the status quo for 22 years without being an issue.
As for benefits: many implementations would now be 'correct' for not complaining
when the feature isn't present (if implementations don't follow the specification,
just change the specification); and there is a minor reduction in data transferred from
having one less feature, though that's less notable where XEP-0115 is used (and there
may be an initial increase caused by most hashes now being unknown, until that settles.)
(Semi-relevant:
https://github.com/xsf/xeps/pull/961 )