Nope, TCP is completely unusable for fast paced games. You cannot read new packets until old ones arrive.
For instance, let's assume players A and B.
Player A sends packets 1,2,3 and 4 to player B.
Player B receives packets 1,3 and 4, but not 2.
Player B can read packet 1, but cannot read packet 2 because it was lost, and it cannot read packets 3 and 4 because it has to wait for packet 2, even though it already received packets 3 and 4. Player B cannot simply "drop" packet 2 until it has received it - it is forced to wait for it's retransmission.
The game hangs in there waiting for a stale packet that is of no use even though it has the data it needs to continue simulating - it cannot read packets 3 and 4 in any way whatsoever, since it is a protocol restriction. Meanwhile, player A is desperately attempting to resend the now-useless packet 2 that was lost.
By the time packet 2 arrives, thus freeing packets 3 and 4, those are already stale (meaning that the data in them is already too old), and player A is already sending packet 10 - if any new packet hangs, the game has to wait again.
Keep in mind this is only a problem for fast paced games - turn based games don't have this problem since there are times where no packets are being sent, allowing TCP to "catch up" without creating delays.
What is the current solution for fast paced TCP games? It's somewhat complex:
The players open multiple TCP connections to each other and begin sending packets alternating the connection that is used. If a packet "hangs", only one connection is affected. This problem is detected, and that connection is dropped and recreated, while the others are retained. Maybe this is something Ashley could look at if the HTML5 UDP solution ends up being underwhelming.