The integrity of the TLS handshake is one of the fundamental and most important promises the TLS protocol makes. This proposal overtly changes the security boundaries of that handshake. It is only because the shout-outs on this I-D are a who's-who of SSL/TLS design that this stands a decent chance at adoption.
TLS clients can do a bunch of different things, but, unlike in SMTP, where it's mostly reasonable to do whatever servers will let you get away with, both sides need to follow the protocol to the letter to make TLS do what it's supposed to do.
You're no longer waiting for both sides to confirm (cryptographically) that they received the same handshake packets. A special mechanism (whitelisted ciphersuites) has to be introduced to ensure that a downgrader adversary can't trick a client into coughing up weakly-encrypted application data by mucking with the handshake.
The TLS handshake is to work out identities and exactly what type of encryption etc they want/support. Then before sending any actual data they encrypt a "Finished" message and both sides verify they can read the message. The server will only be able to create a correct "Finished" message if it has the private key to go along with the presented certificate.
It seems to me like the overt change in the handshake security boundary is that in a FalseStart handshake, a man-in-the-middle attacker can make the initiating side send application data encrypted with relatively arbitrary parameters (until the TLS implementation realizes it can't decrypt the final handshake message properly). There is a good chance this is just annoying (like, on a denial-of-service level of attack) but my intuition is there could be some application circumstances where this is a significant problem. Off the top of my head I can't come up with a specific example however - so I could just be imagining things :)
There are also operating system/application level architecture challenges as well. For example, I'm not sure the idea of FalseStart is compatible with the calling convention of Windows SSL/TLS (InitializeSecurityContext and AcceptSecurityContext) given the separation between transport layer and security context negotiation components. And because of that existing convention, the recommendation in sections 4 and 5 of the draft that "TLS implementations allow the application layer to query whether the handshake has completed" could be potentially tricky for applications using Schannel (Windows SSL/TLS).
TLS clients can do a bunch of different things, but, unlike in SMTP, where it's mostly reasonable to do whatever servers will let you get away with, both sides need to follow the protocol to the letter to make TLS do what it's supposed to do.