I will make three points here:
1. Brute-force attacks are not the main vulnerability of passwords at this point, so debating entropy is a little pointless
Fair enough. The main vulnerability of passwords will always be people. Most people will use the same password or a slight variation on it for just about everything. Heck, even I do that for groups of non-vital accounts. For most people, a phishing site can offer something in exchange for signing up, record the credentials the user enters, then try to log in any number of places and, chances are, if the same person has an account there the same credentials will work. The only real reason to debate entropy is because, usually, when you suggest using combinations of words instead of obfuscated passwords, someone will point out that a passphrase with just a few elements doesn't have as much entropy as a password with more elements. Then someone else has to point out that, since there are so many more possibilities for the individual elements, the passphrase can work out favorably, especially if it's easier to remember. I'm playing that role.
2. Your calculation of 4 sextillion combinations of words is overly optimistic
Not really. There are a quarter of a million English words in the OED. Some of them are obsolete, but that doesn't matter, it only matters that they will be memorable in a passphrase. That's enough for the 4 sextillion (ok, I rounded up by 94 quintillion or so, but we can ignore such a trifling sum) and that's ignoring all the possible forms of all these words and a heck of a lot of nouns that probably drive it north of a million possibilities per element.
Naturally, the actual words people choose for themselves will typically be from a much more limited set. Of course, the same is true of traditional passwords. Things like childs name plus numerical representation of date of birth are a pretty common way to deal with password requirements. I should have been more clear that I think where multi-word passwords work best is when they're generated by the computer for the human to remember, in which case they're typically easier to remember than an equivalently character-based password.
3. And 4 sextillion doesn't even compare that favorably to current password schemes
It actually can, unless you insist on only ever having four words in the multi-word passphrase, but allow the traditional password to be arbitrarily long. You give an example below of a 12 digit password, but realistically most people have passwords shorter than that. 72^2.906286310633014 ~= 250000, so let's just round to 3 and say that you're always going to need three times as many characters as words to beat the multi-word passphrase provided that the number of possible characters/words stays where we speculated.
The poster I replied to was opining that we should stop letting users pick their own passwords. If we do this, then the multi-word passphrase will probably be easier to remember. My preferred solution is to continue to use weak-sauce solutions like user-selected passwords and/or biometrics but to combine them with some sort of secure cryptographic device that the end user carries.
Also, I can't think of any 2-factor authentication that doesn't involve a central authority of some sort, which poses incredible scaling and logistics issues. Since the internet is international, you'd need an international authority. Good luck getting people to agree on one. Cell phones might be the closest thing we have to a consensus, but that obviously leaves out huge populations of the world where that can't be relied on.
I'm thinking of a multi-function crytographic device not tied to one particular scheme. It could theoretically be built into a cell-phone, but would need to have its own dedicated, isolated hardware. The biggest challenge with integrating it with a cellphone would be the problem of securely transmitting data in the clear in an untrustworthy cell phone. All exchanges should be encrypted in some way except for some sort of basic user authentication. The device would be analagous to a physical key, but the downside to a physical key is that it can just be pickpocketed, so the device itself would need some sort of authentication be it biometric or password based or some other method. Capturing the input for that through a compromisable general purpose computing device would be a recipe for disaster. Even having an isolated second keypad or biometric sensor attached to something like a cell phone would be a risk. So, standalone hardware would be infinitely preferable.
As for central authorities, the device could work with multiple central authorities depending on the scheme or, in other cases, it would essentially _be_ the central authority. For example, to work with your bank, you could go into the bank and have the device connected to a secure terminal on a secure network and exchange some keys and a large block (or numerous small blocks) of random data (randomness provided either by your own device or by the presumably trustworthy bank system). All the data stored would be unreadable by higher level functions of the device and only available to lower level crypto-functions built in to the hardware. Automatically deleting the data as it's read would also probably be wise. Basically, it shouldn't be possible to access the actual keys in any way externally without an electron microscope and a lot of patience. The bank computer that issued the keys would treat its own copy of the data in a similar fashion. Ideally, the data would be stored locally with perhaps just enough keys/pad data transferred over a secure network to last a few days with the remainder transferred via armored car to the central authentication server. Then when you use the cryptographic device to perform banking operations, all communications to/from the bank servers would use stored (probably one-time) keys and one-time pads along with any additional security procedures on top of that. Man in the middle attacks might be possible if, for example, you allowed offline transactions, but if you also encrypt using hidden keys and the actual details of the transaction (vendor ID and public key, price, datetime, etc.) it should be very hard to do so.
As for authenticating with websites, generating a hidden key and storing it is at least as secure as providing a password to a website. If they're compromised, they're compromised, but at least you didn't provide them all the information they need to access all of your other accounts everywhere. If they aren't compromised, but end up compromised in the future, then the fake site they put up can't steal your credentials to the real site because you don't know them and your crypto device can't divulge them since you use any of a number of crypto schemes that require both sides to have the hidden key(s) to authenticate. If they're completely compromised so that all of your personal data is in the attackers hands... well, that's outside the scope of a device such as I'm proposing.
You could also use such a device to communicate via side-channels with central signing authorities to authenticate a party you're communicating with. Or use it to log into your work computer, etc., etc. It should be possible to make backups (not of the actual hidden keys and data which obviously should be impossible to read) of all the accounts you have stored on the device so that, in the event of loss or theft, you can rapidly notify all your accounts of your loss and begin the process of creating new crypto profiles.
For better or worse, passwords are probably going to remain the same as they have been for the past decade.
Probably, but I can dream can't I?