1. Senders should first try TLS-on-connect, and if it's not available, fall back to STARTTLS.

2. Senders should only do TLS-on-connect with no fallback

If you do #1, then a downgrade attack still exists because an attacker can just block port 465 and then interfere with the traffic on port 25 (or put a fake SMTP server on that port if one doesn't exist).

If you do #2, that's no easier than just mandating that STARTTLS on port 25 is required.

The alternative to all of this is to find some out of band method for a receiver to state that TLS should be available (TLSA / MTA-STS), and if it's not then something is being tampered with. That way, a sender can look up that information and then choose to do #2 for that particular receiver. Again, in that scenario it makes no difference if we're talking TLS-on-connect or STARTTLS. Given we can't make the whole World switch to "must always be encrypted" at the same time, this is the only practical way forward.

As others have explained an on-path adversary who'd be able to rewrite packets in order to stop STARTTLS can even more trivially block port 465 altogether. In fact cheap appliances can do the latter but can't do the former, so if anything STARTTLS very slightly improves this.

If you are imagining "Well I could have a policy of only using port 465" well, sure, but you could just as easily have a policy of requiring STARTTLS. In both cases an adversary can deny you, and your only options are to re-think your policy or give up and not deliver email.