tl;dr:
- Because neither implicit nor explicit TLS is technically that bad;
- Because changing ways the Internet works takes time.
This is essentially not one, but two different questions, and I'll address them separately.
1. Why are common services using implicit SSL not considered obsolete?
As you may have already noticed, in recent years, large corporations such as Google or Facebook have put a lot of effort in securing HTTP communications, and largely succeeded at that. But one of the main drivers for that seem to be ISPs replacing Web ads with their own, which severily harms Google's and others' business models.
By the way, the implied consequences of this are huge, the very structure of the Internet is going to change a lot as the result. Geoff Huston from APNIC has summed it up in his excellent blog post and related presentations (slides, video), so I'd better just refer to that without explaining it further here.
There are, of course, other drivers as well, but a lot of them are still heavily bound to securing someone's business models (e.g. PCI SSC activities and so on).
What's most important here is though those achievements in HTTP area raise a bar pretty high, many other ways of communication, including e-mail, seem to lack that sort of commercial drivers HTTP luckily has, and this is probably one of the main reasons their security stays rather obsolete, compared to what we have currently in HTTP. As the result, in 2018, it's still necessary to support a great number of outdated mail access servers, user and transfer agents which are only able to communicate in cleartext.
Hopefully this will change, but I personally can currently offer no clear estimations for that.
Both implicit and explicit TLS approaches are better than cleartext, as securing communication either way is better than not securing it at all. Some MUAs and MTAs deployments out there only support either implicit or explicit TLS, and deprecating any of the concepts leaves those deployments without any countermeasures against MitM attacks. Deprecating protocols and methods that are used actively on the Internet — and are essentially better than nothing — in favor of nothing is a bad practice.
As you can see, deprecating SMTPS alone haven't done us any good: it's still there in the wild. This is an example that a widely used Internet protocol couldn't be just shut down at will. Right, sounds funny, but back in circa 1998 when it happened it might have been less clear than it is today.
Moreover, declaring one of the concepts outdated in favor of the other must be supported by the Internet community, and though most people agree there should be only one of two options left as preferred at the end of the day, it's not that easy to reach consensus on whether explicit TLS is better or not (more on that below). The Internet draft you're pointing to is a fundamental initiative towards bringing a piece of sanity in all this mess without bringing up a common standards dilemma:
Once it's finalized, a process of explicit TLS deprecation would start at some point in future, but it will take time.
2. Why explicit STARTTLS should be considered a better option?
A disclaimer: this is simply an outline of current approaches towards the Internet protocol design. I'm not taking sides here, the right places for objections against those approaches are IETF working group mailing lists and meetings.
Implicit TLS is great for protocols which are designed from scratch, with contemporary threat models in mind, and which lack the requirement to support cleartext communication. However, implicit TLS is somewhat a controversial approach with regard to securing old cleartext protocols. It seems to be working fine for HTTPS, but it required some effort, including allocation of a different port (443) for secure HTTP communications.
The downside of this approach is that for each remaining cleartext protocol, you'll need to allocate another TCP/UDP port, while the global TCP port space is severily limited. At some point, IETF working groups generally considered wasting ports this way a bad practice, and even port 465 (originally SMTPS) was later reallocated for a different purpose (this actually happened about 20 years ago, which as well sheds some light on how slowly the Internet adopts changes).
Again, as you can see in draft-ietf-uta-email-deep, this consideration might be withdrawn in the near future. Note also that this draft originally dates back to year 2013 and is now only approaching the final state, which gives you an idea of how hard this choice is overall.
The general idea of opportunistic (or explicit) TLS is to somehow inform a client in advance (using a different communication channel, already verified before and thus trusted) that a particular remote server supports STARTTLS, so the client must only use STARTTLS for data transfer towards that server, thus preventing STRIPTLS attacks. Originally DNSSEC was supposed to provide this separate channel, however, its worldwide deployment has somehow stalled, and as the result, working groups are considering other ways (e.g. TOFU) to do that.
Note that the implicit approach itself is not downgrade-resistant as well, as a man in the middle is able to strip implicit TLS. Approaches like HSTS depend on TOFU themselves. A common argument is that a user can force their software client into secure communication by explicitly specifying a port number in client preferences, but a software client can also provide user with an ability to explicitly enforce STARTTLS on an old port, so from the user's perspective the difference between two approaches is subtle.
