Where "larger" really means Google and Yahoo, others as you now see are less zealous about MTA-STS as the main way forward (there's little sign of broad adoption beyond a small number of the largest providers).

For Google, part of the issue is that signing "google.com" where the MX hosts live is a non-trivial endeavour given all the DNS-based load-balancing kit that's deployed at scale. That can be solved by e.g. switching the MX hosts to another domain, e.g. "smtp.goog" which is signed, and already has mx[1-4].smtp.goog as alternative MX hosts for the same domains (gmail.com and all the G-suite hosted ones). All that's required is TLSA RRs for these, and presto-magic, inbound DANE for Google-hosted domains that are signed and have designated these MX hosts (some already have, despite lack of official guidance from Google that these are supported, nagging for such guidance continues...).

And of course gmail.com could be signed without having to sign google.com, so given willpower to get it done, technically they have a simple way forward.

For yahoo.com, there's no separation between the email domain and the (does anybody still care about it) website. So DANE SMTP for yahoo.com could be more difficult, but again not insurmountable, if they still have any resources left to get new things done. If they're only on life-support, then probably not any time soon. (I'm still waiting for native IPv6 from Verizon Fios...)

Another significant obstacle is perhaps internal politics. There is sadly some quasi-religious zeal (feels like in-group vs. out-group territoriality) around "dislike" of DNSSEC. True believers in the faith are wiser and more prescient than us unenlightened masses, and have been effective barriers to progress in more than one organization.

There's of course work to be done to improve DNSSEC usability (with significant progress in e.g. BIND 9.16 automating key rollover, not just resigning), especially the interface between registrant and registrar, where CDNSKEY/CDS support would remove barriers to KSK management.

It would be great to see more domains upgrade from RSA-2048 KSK + RSA-1024 ZSK to ECDSA P-256, or at least at a 1280-bit RSA ZSK, with adequately frequent (~90 day or so) ZSK rollover. For RSA, algorithms 5 and 7 which use SHA-1 signing (now deprecated) need to be upgraded to 8 or 10 which use SHA2.

Internet-scale infrastructure changes take effort and time, and if you're not actively participating, at least try to not get in the way.