While I generally agree with your gist here I feel compelled to point out that with regard to CVE-2013-1667 point 4 is plain wrong, and that 5, while attempting to make a valid point contains inaccuracies and appears to be based on the mistaken understanding that CVE-2013-1667 is a normal hash collision attack.

Point 4 is plain wrong because a successful attack requires much less keys than you realize. I feel obliged to be coy about how many but rest assured the number is small enough to be a real threat.

Point 5 contains a valid point that this attack is probably of concern only to business scale installations. However the rest of the points it makes are at best applicable to a standard hash collision attack but do not apply to the REHASH attack at all. Specifically, the REHASH attack is *proven*, (or there would be no one-line test for it), requires no probing, and far from being "almost impossible" is actually trivial execute. To attack various web platforms one would simply construct an URL containing the right keys as parameters to the request, and since the proof of concept attack requires only chars in "a-z" doing this is trivial.

Anyway, with regard to true hash collision attack I generally agree with your line of thinking in this post, and indeed my paper on it said more or less the same thing. But the REHASH attack is in a different category, and should not be confused with a classical hash collision attack.