I must admit that I don't know how widely supported these are. I doubt they are widely used.
Introducing new standards is often a chicken-or-egg problem. Why would anybody spend time on implementing a standard that nobody else supports?
SMTP parameters is a general mechanism which is potentially useful also for future standards. If parameters were supported in Net::SMTP, early adopters could more easily start experimenting with new standards and in that way encourage others to do the same.
Regarding SMTPUTF8:
There has been talk about email addresses with non-ASCII characters on the left and right side of the @ sign for ages, and different approaches have been published in RFCs over the years. After a decade or two of patience, non-ASCII domains finally work in web browsers. Email is not there yet, but I feel confident that it will get there eventually, based on SMTPUTF8 or something else.
Both Gmail and Outlook.com announces support for SMTPUTF8 in their EHLO response, but AFAIK they do not allow users to create email accounts with non-ascii characters. I suspect they don't want to offer such addresses, because using such an address in practice is an uphill struggle due to lack of support in other parts of the email ecosystem (including Ruby-based applications :-)).
If Gmail started offering non-ascii email addresses tomorrow, Net::SMTP would not be able to send to those addresses in an RFC-compliant way. Gmail might just accept the addresses anyway without requiring SMTPUTF8 keyword, assuming that most SMTP servers just pass the 8-bit addresses through without validation. But trying to stick to RFCs seems like a safer choice.
Regarding REQUIRETLS:
This is a fairly new standard (RFC published in late 2019). That alone indicates that people in the RFC community considers this an important issue to address. I am somewhat skeptical whether REQUIRETLS will get enough traction. The issue of enforcing TLS in outgoing emails could be addressed in a simpler (but less flexible) way, e.g. using a global setting in the SMTP server.