Turbines really don't do well with stops and starts, particularly when hot. If you could setup a system where the turbine ran continuously for a longish period and then shut down for a full cool down cycle: then yes, I think it might be a good match...but in general that load pattern doesn't match very well with automobile transportation. Perhaps batteries really are large enough now to make that work.

My experience with turbines has been that startup is always a risky operation and that every start has a small but real chance of causing catastrophic failure. Its hard for me to imagine they'll ever be robust enough for mass market use in something like an automobile....but who knows, technology is always getting better.

No, you really don't understand what this is useful for. They aren't "reinventing TCP" because they think they can do it better: they have a different problem domain and can do better than TCP for their specific problem.

TCP insists on strong ordering of data: it provides reliability AND ordering. Sometimes you don't want both of these, and giving up one or the other can get you big benefits.

For example, there are many classes of problems where you want reliability but are willing to lessen the ordering requirements (networked gaming is a common example) because you want the lowest possibility of latency. By not requiring a strict ordering you can avoid stalls and get data sooner: when a packet is lost in TCP the driver has to buffer the data until it gets retransmitted. For a concrete example, if packet #99 in a TCP stream is dropped, even though your machine has received packets 100-2000 it can't give them to your application until 99 has been retransmitted....since the TCP contract is for strict ordering. This leads to significant latency effects under packet loss, and is one of the reasons why people use UDP.