The situation we are in now is a little like trying to put the toothpaste back in the tube.
You can run an implicit SSL SMTP server on port 465 (port 993 is IMAPS, btw) and other could connect, but a much larger percentage of the SMTP servers out there don't do this versus those that do. The only way you would know is if you attempt a connection first (which will most likely fail), and then you have to fall back to regular port 25 anyway, thus increasing the overhead for sending emails.
Fundamentally, an implicit SSL connection and a clear text connection where you issue STARTTLS are the same, but the advantage of STARTTLS is that you only have to connect to one port (which should always be open for any public SMTP server), and you can then secure up the session. Granted, you might have the fallback to an unecrypted session depending on the client/server config. It is possible to set up some SMTPd servers to require TLS when connecting to remote servers, even by using STARTTLS, but you still end up in the same situation (many servers do not support it).
Now, if the government enable STARTTLS functionality for inbound and outbound, it still relies on the other client and server to support it. They can't force that to be the case, and if it's not supported on the other end, it defeats the implementation anyway. Thus, implementing the change might give some a false sense of security just to tick another box on the security checklist. I'm not saying they shouldn't implement this at all, however.