Downgrade attacks are active attacks.
Active attacks are much easier to detect, and are typically more difficult to perform, than their passive counterparts.
Opportunistic encryption, such as optional STARTTLS in SMTP, mainly protects against passive surveillance where traffic is undetectably either analyzed while in transit, or stored for later analysis. You are perfectly correct that opportunistic encryption doesn't protect against active attacks. Opportunistic encryption in general simply doesn't try to protect against an attack where the attacker is able and willing to modify the data in transit; that's outside its scope. Similarly, opportunistic STARTTLS doesn't protect against a rogue mail server passing the data on to a third party; that's outside its scope.
At least some SMTP servers (the rather popular Postfix being one of them) can be configured to require TLS when sending (or receiving) mail, either globally or manually on a per-MX basis for outgoing mail. When configured like that, if STARTTLS fails or is unavailable (regardless of the reason why that is the case), the SMTP session can be rejected, based on locally configured policy.
While active attacks certainly do happen, there is good reason to believe that passive traffic monitoring is widespread on today's Internet. Pervasive monitoring is an attack which often can, and certainly should where possible, be mitigated.
Therefore, even if opportunistic encryption does nothing whatsoever to protect against active attackers, it's a win because it prevents passive traffic monitoring and surveillance from learning more than necessary about the data being communicated. The same argument would apply to unauthenticated HTTPS as well, in that even though it wouldn't protect against every attack, it would still be an improvement over communicating entirely in the clear from a communications privacy point of view.
There's a standard, RFC 8461 SMTP MTA Strict Transport Security (MTA-STS), which can be used to specify that mail server traffic for a given domain requires TLS. That standard is still pretty new (the RFC is dated September 2018), so I would expect support for this to be spotty, but again, as long as everything is set up correctly, to publish a MTA-STS policy will, at worst, result in no improvement of communications privacy (because a MTA that does not implement MTA-STS will simply act as if no MTA-STS policy at all was published, while a MTA that does implement MTA-STS correctly will be able to take the published MTA-STS policy into account for policy decisions).
In addition, there is a standards track SMTP extension, REQUIRETLS, which can be used to specify that transport-layer security should be prioritized over message delivery.
Even though downgrade attacks are possible with purely opportunistic encryption, that doesn't mean that purely opportunistic encryption is worthless. It just means that there are threats that purely opportunistic encryption doesn't address; which is no different from the fact that there are threats that required encryption doesn't address.