I think there’s a reason those are also optional. They are certainly nice to have, but I’d say it’s arguable if they should be required, as they are not strictly necessary to facilitate uploads.
This is mostly mitigated by knowing the exact length of bytes for the final upload. It’s not bulletproof, but can be considered good enough for the minimum required verification imo.
The expiration extension is obviously nice to have, but a file would just be incomplete until it’s deleted, when that’s not implemented. The server can also prune after a while, regardless of an extension spec. I think the idea of the expiration extension is that if a server has heavy load, and especially public uploads enabled, then the client can know when to give up on a slow, ongoing upload. But without the extension, you would just receive back a upload byte offset of 0 for the next PATCH in case the partial file has been pruned. Which is surely an edge case until RS is a widely used standard and clients attempt monster uploads of massive files in the first place.
The termination extension is already exactly the same as what RS would do, namely a DELETE request to the resource, which should just remove whatever is there–complete or not-- by simple HTTP semantics and existing RS protocol spec. So any RS server already supports that extension by design.