Google and Yubico just announced the availability of cryptographic security tokens following the FIDO U2F specification. Is this just another 2FA option, or is this significantly better than solutions such as SecureID and TOTP?

Specifically: 


In what way is U2F fundamentally different from OTP?
How does U2F affect the feasibility of phishing attacks in comparison to OTP systems?
How feasible are non-interactive attacks against U2F (e.g. brute-force, etc)?
Can I safely use a single U2F token with multiple independent services?
How does U2F stack up against other commercial offerings? Are there better solutions available?


The answers I've gotten have been good, but I wanted to provide a bit more depth, going specifically in to why the system exists at all, which should explain a bit more about what it's good for.

Disclaimer: While I now work for Google, I knew nothing about this project at the time this answer was written. Everything reported here was gathered from public sources. This post is my own opinions and observations and commentary, and does not represent the opinions, views, or intentions of Google.
Though it's worth pointing out that I've been using this and tinkering with it for quite some time now, and as someone who has dealt a lot with social engineering and account takeovers, I am disproportionately impressed with what has been accomplished here.

Why something new was needed
Think about this: Google deployed two-factor authentication a long time ago. This is a company that cares deeply about security, and theirs has been top notch. And while they were already using the best technology available, the additional security that U2F delivers above traditional 2-factor is so significant that it was worth the company's time and money to design, develop, deploy, and support a replacement system that they don't even themselves sell. Yes, it's a very socially-conscious move of them to go down this road, but it's not only about the community. Google also did it because they, themselves, need the security that U2F alone provides. A lot of people trust Google with their most precious information, and some in dangerous political environments even trust Google with their lives. Google needs the security to be able to deliver on that trust.
It comes down to phishing. Phishing is a big deal. It's extremely common and super effective. For attacks against hardened targets, phishing and similar attacks are really an attacker's best bet, and they know it. And more importantly:
Our phishing protection is laughable. We have two-factor auth, but the implementations offer little defense. Common systems such as SecurID, Google Authenticator, email, phone, and SMS loops -- all of these systems offer no protection at all against time-of-use phishing attacks. A one-time-password is still a password, and it can be disclosed to an attacker.
And this isn't just theoretical. We've seen these attacks actually carried out. Attackers do, in fact, capture second-factor responses sent to phishing sites and immediately play them on the real login page. This actually happens, right now.
So say you're Google. You've deployed the best protections available and you can see that they're not sufficient. What do you do? Nobody else is solving this problem for you; you've got to figure it out.
The solution is easy; Adoption is the real issue
Creating a second-factor solution that can't be phished is surprisingly simple. All you have to do is involve the browser. In the case of U2F, the device creates a public/private key pair for each site and burns the site's identity into the "Key Handle" that the site is supposed to use to request authentication. Then, that site identity is verified by the browser each time before any authentication is attempted. The site identity can even be tied to a specific TLS public key. And since it's a challenge-response protocol, replay is not possible either. And if the server accidentally leaks your "Key Handle" in a database breach, it still doesn't affect your security or reveal your identity. Employing this device effectively eliminates phishing as a possibility, which is a big deal to a security-sensitive organization.
Neither the crypto nor its application is new. Both are well-understood and trusted. The technology was never the difficulty, the difficulty is adoption. But Google is one of only a small number of players in a position to overcome the barriers that typically hold solutions like this back. Since Google makes the most popular browser, they can make sure that it's compatible by default. Since they make the most popular mobile OS, they can make sure that it works as well. And since they run the most popular email service, they can make sure that this technology has a relevant use case.
More Open than Necessary
Of course Google could have leveraged that position to give themselves a competitive advantage in the market, but they didn't. And that's pretty cool. Everyone needs this level of protection, including Yahoo and Microsoft with their competing email offerings. What's cool is that it was designed so that even competitors can safely make it their own. Nothing about the technology is tied to Google -- even the hardware is completely usage-agnostic.
The system was designed with the assumption that you wouldn't use it just for Google. A key feature of the protocol is that at no point does the token ever identify itself. In fact the specifications state that this design was chosen to prevent the possibility of creating a "supercookie" that could be used to track you between colluding services.
So you can get a single token and safely use it not only on Gmail, but also on any other service that supports U2F. This gives you a lot more reason to put down the money for one. And since Yubico published reference implementations of the server software in PHP, Java, and Python, getting authentication up and running on your own server is safely within the reach of even small shops.
