Implementing TLS securely owes its difficulty partly to the variety of ciphersuites and optional features that all need to be securely implemented. Building a simpler protocol which suites some specialized needs will make the number of ways in which you can screw up considerably smaller.

The StackOverflow answer you are linking to suggest hardcoding the server public key in the client (as was my idea) and then throwing away the whole server certificate. This means that the server wastes its precious time to send an X.509 certificate which the client will essentially discard (and it will add to the packet size, too). My protocol is currently very similar to TLS_RSA_WITH_AES_128_CBC_SHA256 mentioned in the answer. I'm using RSA, AES-256 in CBC mode, and SHA-256 HMAC authentication. I'm thinking of maybe switching from AES-CBC+HMAC to AES-GCM, but modifications to the protocol won't be hard if I get everything up and running smoothly.

I am, too, highly skeptical that I will come up with anything that is both faster and more secure than TLS. That's why I am open-sourcing it and not even thinking about trying to profit from it. I'm doing this for my own satisfaction, and if that results in something that will help others, that would be even better.

I don't have a problem with using TLS for secure communication in the client-server API case, but also with stuffing HTTP up there. This requires people to run a web server that will serve the API calls, and I conjecture that there is non-trivial overhead of the call going through the HTTP layer and getting dispatched to a script interpreter. And the cost is twofold because the response must get back from the interpreter, to the HTTP layer, augmented with an ASCII header and sent back through the TLS layer to the client application.

As part of this, since the scripts on the server are PHP currently (but with an ability to change this fairly easily), I'm working on a more lightweight FastCGI alternative that sacrifices some of FastCGI's aspects (such as running the FastCGI daemon on one host and calling into the scripts from another) but dispatching a request to a PHP instance (which I keep preforked, with a couple of spare ones, much like Apache does for its own processes) is essentially a zero-overhead operation.

I'm trying to be as secure as I can, attempting to mitigate timing and other side-channel attacks as much as vulnerabilities in the protocol itself. That's why I'm reusing a lot of the TLS ideas, but working in my own down there. I'm going to try to get trained cryptographers to review both the protocol and the code, but I don't aim to provide any warranty.

I'm aiming to build a better solution not for TLS, but for secure HTTP RESTful APIs when the client can know server information beforehand. It's a lot narrower use case and I think I can tackle it more effectively, and if it turns out to be a dead end, I'll have some experience on my hands. And the server I'm building is highly modular, so some parts (especially the threadpooled libuv-based protocol-agnostic backend) may be reused later if deemed appropriate.

I have absolutely zero problems with experimentation, I like doing that as well.

My primary concern is with people (and I'm not claiming that you are one of them) publishing such experiments without huge "This should not be used in production!!!" warnings and some poor fool deploys it and gets pwned 3 months later.

TLS does have some overhead because of its flexibility, yes. But it's still incredibly fast and should not be a bottleneck in most scenarios. Given that it has been battle-tested with very little flaws found (most bugs are implementation bugs, not protocol bugs), it is and will be for the foreseeable future the #1 option for anyone looking for a encrypt-data-while-in-transit solution.