The answer, based on the STARTTLS RFC for SMTP (RFC 3207) is:
STARTTLS is less secure than TLS.
Instead of doing the talking myself, I will allow the RFC to speak for itself, with the four relevant bits highlighted in BOLD:
A man-in-the-middle attack can be launched by deleting the “250
STARTTLS” response from the server. This would cause the client not
to try to start a TLS session. Another man-in-the-middle attack is
to allow the server to announce its STARTTLS capability, but to alter
the client’s request to start TLS and the server’s response. In
order to defend against such attacks both clients and servers MUST be
able to be configured to require successful TLS negotiation of an
appropriate cipher suite for selected hosts before messages can be
successfully transferred. The additional option of using TLS when
possible SHOULD also be provided. An implementation MAY provide the
ability to record that TLS was used in communicating with a given
peer and generating a warning if it is not used in a later session.
If the TLS negotiation fails or if the client receives a 454
response, the client has to decide what to do next. There are three
main choices: go ahead with the rest of the SMTP session, […]
As you can see, the RFC itself states (not very clearly, but clearly enough) that there is NOTHING requiring clients to establish a secure connection and inform users if a secure connection failed. It explicitly gives clients the option to silently establish plain-text connections.