The gist of "TLS false start" is that, at the end of a normal TLS handshake, each party sends a Finished message to the peer, and should wait from the Finished from that peer before sending application data. "False start" removes that "should wait". Each party may then send application data right away. This implies a lower latency if the party which sends the Finished first is also the one who would send applicative data first.
Note that there are two kinds of TLS handshakes, the "full" and the "abbreviated" handshakes. The latter is used to "resume" a TLS session, namely to recompute a new session key over an already exchanged master key; the abbreviated handshake uses only symmetric cryptography and requires less network exchanges. A point which is worth noting is that in a full handshake, the client sends its Finished message first, whereas in an abbreviated handshake, the server sends its Finished message first.
In the context of HTTPS and Web sites, the client (a web browser) normally initiates a single full TLS handshake. Then the client may also open a few other parallel connections, this time using abbreviated handshakes. Each connection will be used to send several HTTP requests. If a connection timeouts, the browser will open a new one using yet again an abbreviated handshake. Since HTTPS is HTTP-within-TLS and HTTP begins by a request from the client, the "false start" optimization yields any improvement only for the very first HTTP request within the very first TLS connection to the server. This is not really a free lunch, rather a free appetizer, at most.
Cryptographically speaking, what happens with false start is that the client accepts to send its data (the HTTP request) before having confirmation that it really talked to the true server: at that point, from the client point of view, the server is implicitly authenticated. The applicative data is encrypted with a session key derived from a key exchange which used the authenticated server public key (the one from the server certificate) so there is no real risk that an impersonating attacker could gain information that way, at least as long as the key exchange algorithm and symmetric encryption algorithm are secure. However, the client does not have any proof, when it sends its request, that the intended server is really aware of the connection attempt. This is harmless in the context of HTTPS. It would be bold to assume that there is no harm in it generically.
