Sure, but wouldn't it be better to reduce those when possible, rather than adding another one, especially yet another under the control of a third party?

On the whole, yes, but that's not realistic if you're a developer and you want to deploy some devices. You can't just expect people to rearrange their whole networks for you.

This certainly was an issue in early days of P2P, but I thought it was already solved for good.

Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)

Indeed, NAT-piercing isn't new or even revolutionary. It's a small feature of our mission to make building IoT apps as painless and fast as possible.

Our main goal is to build an ecosystem of ready-to-use devices and a RESTful API around this ecosystem so devs can focus on building their awesome IoT application, rather than bothering with the infrastructure. This is a component of that effort.

I don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone).

You could run a server in the middle; but that's exactly what this is.

> I don't think NAT piercing works if both of the endpoints are behind NAT

It does, in many cases even without on any third party. That is a (mostly) solved issue for at least 5 years or maybe even more. Here are examples of such tools: http://samy.pl/chownat/ and http://samy.pl/pwnat/

There are cases such tricks won't work (like overly conscious connection tracking engine and all ICMP traffic blocked - but without ICMP one would have PMTU issues and those ain't fun), but there're always STUN and TURN. The distinction is, those is not middleman, but just a NAT piercing helpers. They don't pass your traffic through and they're generic and useable with any service.