Well... no, it doesn't, obviously, we can take a quick look at gawk to confirm this.
But, just as we can't say "awk offers the -b flag to process characters as bytes", we can't really say that cut offers any extensions not defined in the standard.
An implementation could, sure. I'd prefer that it didn't, writing conformant shell scripts is hard enough.
Before standards happen, creative developers are free to use their imagination and come up with useful features. Then someone makes up a standard, and from thereon progress is halted. The only way you grow new features and functionality is through design-by-committee, if people aren't making extensions that would one day make it to the next revision. I think it is ridiculous.
Tools should improve, and standards should eventually catch up & pick up the good parts.
People who need to work with legacy systems can just opt not to use those extensions, but one day they too will benefit. Others benefit immediately.
I find that, for these kinds of utilities, all the extra add-ons tend to cost me more in the form of, "Whoops, we tried using this on $DIFFERENT_UNIX and it broke," than they ever save me.
When I'm looking to do something more complicated, I'd rather look to tools from outside the POSIX standard. The good ones give me less fuss, because they can typically be installed on any POSIX-compliant OS, which is NBD, whereas extensions to POSIX tools tend to create actual portability hassles.
But, just as we can't say "awk offers the -b flag to process characters as bytes", we can't really say that cut offers any extensions not defined in the standard.
An implementation could, sure. I'd prefer that it didn't, writing conformant shell scripts is hard enough.