No. Developers should continue to use TLS.
If you look at the last few years of TLS --- which have been rocky, to be sure --- you have flaws that are really difficult to exploit and (usually) straightforward to mitigate. If you look at a representative sample of non-TLS transport protocols, you get clownish flaws:
* Block ciphers deployed in the default mode (ECB), which allows straightforward byte-at-a-time decryption
* Error-based CBC padding oracles for which off-the-shelf tools will do decryption
* Unauthenticated ciphertext --- not "used a MAC in the wrong order", like Lucky 13 exploits, but "literally no integrity checks at all", so attackers can trivially rewrite packets
* RSA implemented "in the raw" with no formalized padding or PKCS1.5 padding
* Key exchanges with basic number theoretic flaws
* Repeated IVs and nonces that allow whole message decryption by analyzing captures of just a few hundred messages
The list goes on and on. Not only that: two of the recent 4 TLS problems (BEAST's chained CBC IVs and CRIME's compression side channel) are equally likely to affect custom cryptography --- they aren't the product of any weird SSL/TLS requirement. Chained CBC IVs also happened in IPSEC; compressing before encryption was IIRC an _Applied Cryptography_ recommendation. The only reason the RC4 bug is unlikely to apply is that nobody outside of TLS server operators would choose RC4.
To be sure: your best options (PGP and TLS) are creaky and scary looking. But they are nowhere nearly as scary as the "New" cryptosystems people deploy. What's especially annoying about the new stuff is that they follow a release cycle that conceals how terrible they are:
* Initial release with great fanfare about the new kinds of applications they'll enable, press coverage
* Security researchers flag unbelievably blatant flaws in crypto constructions
* Blatant flaws are fixed, cryptosystem is rereleased, now with promotional text about the external security testing it has
For a cryptosystem published by someone without a citation record in cryptography, a basic crypto flaw should be considered disqualifying; it's a sign that the system was designed without an understanding of how to build sound crypto. But that's not how things actually work, because everyone wants to believe that cryptographic protection is the Internet's birthright and that we're all just a few library calls away from "host-proof" or "anonymous" communications.
If you're really worried about TLS security but have the flexibility of specifying arbitrary crypto, why not use a library that does TLS with an AEAD cipher, like AES-GCM?