There does appear to be some confusion with point 1.
The confusion probably stems from the fact that Keccak has an output size number and a capacity. Output size has little to no effect on security strength. Capacity is what really determines the security strength. So when the post says NIST will only standardize two security levels it is correct (as far as the presentation goes, which is in no way set in stone, see below) and that the original proposal had more levels than this. I'm betting when many people read this, however, they are confused and thing that there are only two output sizes.
This slide from Kelsey's presentation at CHES2013 says that there will be 4 different output versions (224, 256, 384 and 512) as well as 2 variable length output versions. There are only two capacities though (256 and 512) and therefore 2 security levels.
A few slides later we read "Security level determined by hash funcion internals, not
output size". I think this could be very confusing for developers who have always been told in the past that the probability of collision is the output bit length divided by two (due to birthday attack). Instead, now the collision probability will depend on the internals which developers will never interact with. It also raises the question, why have 2 different output lengths (224 and 256) when both offer the same bit strength (128 bit)?
Another point comes a few slides later "Preimage strength = collision strength". This is a big difference from what developers are familiar with. And on the same slide NIST admits "But this is a pretty big change from the submission". So the security strength of SHA3-256 against preimage attacks will be 128-bit instead of 256-bit like we would expect with SHA2-256.
At the moment, we typically assume that a security level of around 80 bits is sufficient for security these days. So the proposed versions should be fine for now. The fact that the preimage security levels are different from what we have been use to in the past is somewhat disconcerting in my opinion as it is technically weaker than the same sized output SHA2 functions. Similarly, the confusion around security levels and output length given what developers are use to today cannot be a good thing. Shoot, it is even causing confusion among NIST folks (see this other presentation).
As for the second point, this slide from the same presentation mentions the padding changes. I'm not all that familiar with this, so I can't really comment on how this affects security.
Update
I think it should be noted that as far as capacity goes, NIST has not decided on anything. I just saw an email on the SHA3 competition mailing list from John Kelsey where he lists the following 3 possibilities of what NIST could do (implying that it isn't decided).
Possibility #1: They all get capacity of 512 bits, and so promise 256 bits of security. Since 256 bits of security is the highest level that NIST is concerned with, this makes some sense, but it still leaves the process concerns since it's not the version that was submitted, and is in fact weaker, if only in a competely theoretical way. (That is, it's weaker if you are concerned with attacks requiring more than 2^{256} work.) It also doesn't work if you somehow believe that n-bit fixed-length hash functions must have an indifferentiability bound of n bits, though I do not see why that requirement particularly makes sense, and if we'd chosen one of the other candidates that couldn't support it, I don't think anyone would be bringing it up now.
Possibility #2: SHA3-224 and SHA3-256 get 512 bit capacity, SHA3-384 and SHA3-512 get 1024 bit capacity. This is no weaker than what was submitted, and preserves preimage resistance and the indifferentiability bound of n bits for n-bit hash functions. But the performance hit on 384 and 512 bit hash sizes is pretty substantial, and there is zero practical security benefit from this.
Possibility #3: SHA3-224 gets 448 bits, SHA3-256 gets 512 bits, and so on to 1024 bits of capacity. This is just #2 with more distinct capacities, but it is precisely what was submitted to SHA3, and it gets somewhat better performance for SHA384.
So, when point 1 says "the SHA-3 standard will only offer 128-bit and 256-bit versions." That is simply not true at the moment as the SHA-3 standard has not been set in stone and changes are still being discussed. Thus we do not know what the standard will offer.