The nut of this story: use SHA256 until NIST selects a "winner" in a couple years. Schneier's team submission will be competing with submissions from better-regarded cryptographers, and everything submitted to this contest is unusually liable to be broken due to the competition.
Just so you know, you're reading about Skein because Schneier has an extremely popular blog and is a well-known personality. He is less well-established as a credible cryptographic researcher, as a Google Scholar search will establish. He has a smart team, and his last NIST submission (Twofish) was an AES finalist, but you'd get looked at funny if you were caught using Twofish in 2008.
None of the AES finalists have been "broken", and all of them (except maybe I think Serpent?) have had cryptanalytic results published in the literature. It is indeed because AES is the standard --- everybody uses it, there are many good-quality implementations, and everybody knows how to use it.
It's all kind of a moot point. If you're typing the name of a cipher into your code, you're doing it wrong, and you'll pay down the road when you get pentested.
Why isn't the submission process anonymous, anyway? (granted, according to the design of the algorithm you may be able to deduce the team who is behind it.)
One obvious reason is that unlike, say, SIGCOMM (which is also not anonymous) the authors will need to defend their submissions over multiple rounds of challenges. It's not a "everyone throw your stuff over here and NIST and the NSA will sort it out" kind of thing: the crypto results that select the winner come from research the contestants themselves will in part be doing.
I'd like to see how it goes. Among some of the submissions I viewed, it is the fastest one which make it very practical to replace now file digest method. But I do not want to adopt the method now as it is not be widely accepted yet. As there are other interest algorithms out there (more than using block cipher) like using properties of log func. From my own perspective, I do prefer different ideas.
A secure hash function is a cryptographic primitive. Its goal is to resist collisions, particularly preimages (predictable collisions), while being as fast as possible. To steal Schneier's words, hash functions are the glue that binds most cryptosystems (like SSL/TLS or PGP).
A password storage function is a cryptosystem built out of crypto primitives. The primitives are designed to be fast, but the cryptosystem should be slow. One of the goals of a password storage function is to find a reasonable, flexible way to slow down fast crypto primitives.
So the problem here is just terminology; you're conflating password storage functions with hash functions.
And now you have another perspective on why "salted SHA256" is an evil password storage function: it's simply using a raw hash function, rather than building a password storage function out of them.
Also: you can't really "build tables" out of any password storage function with a nonce ("salt"); defeating "tables" is as simple as adding a public random number to each password. I'm writing this because it's worth remembering that "building tables" is just one of many attacks against a password storage function, and it is not the most important one.
Just so you know, you're reading about Skein because Schneier has an extremely popular blog and is a well-known personality. He is less well-established as a credible cryptographic researcher, as a Google Scholar search will establish. He has a smart team, and his last NIST submission (Twofish) was an AES finalist, but you'd get looked at funny if you were caught using Twofish in 2008.