Wait, so coins that are highly GPU mineable but don't have a public GPU miner (it would have to be a public highly-optimized GPU miner, right?) for at least 20 days are not also Cripplemined by your definition? How many coins were mined in those 20+ days?
Where do you draw the line here?
Quark, with just 5 of the hashes, was a "cpu coin" for months. It took the "crowdfunded" GPU miner of darkcoin to then be used for quark also.
Actually what Darkcoin did, I doubt anyone has done in terms of mining fairness. "We are funding the development of GPU mining before anyone gets to develop it in private"... Who does that?
As for cripplemining, well, the issue with Monero was
1)
it was intentionally crippled to be slower.It appears from the simplicity of the fix that there may have been deliberate crippling of the hashing algorithm from introduction with ByteCoin.
Interesting. Could you extrapolate on this?
oaes_key_import_data calls are placed inside loops unnecessarily, which slows down the hash quite a bit during the scratchpad portions.
Wow, I just saw that. I agree with tacotime, it looks intentional.
So you mean the BCN engine was curbed all this time, and they just add to remove it to artificially increase it?
That's disgusting.

2) There were people mining with at least double the speed and the devs were ok with it:
Blame BCN developers - instamine yourself. Nice catchphrase you got here
And here i thought people went to MRO to have a clean start but nope! instamining it with a fast linux hash... Cool!

You're welcome to optimize your own miner if you're so interested; you have the source code. Artforz GPU mined Bitcoin for a long time on his private OCL code on 4870s and got thousands of them. Bitcoin survives to this day, or so I'm told.
You're the developers after all.
It's a good approach for a developer: we're instamining - you can too, if you're good enough! Promising coin - no shit. 

+
3) There was a known cpu miner going much faster:
Hey,
NoodleDoodle optimized the slow hash code recently to about 225% performance. However, he has decided not to release the source code and has only released binaries. I think he is enjoying mining MRO with very high hash rates from Linux right now. Eventually we hope he will release the code.
Hope dies last

And we also have a "catastrophic" problem with PoW:
Problem is that
AES is not suitable as a hash (certainly not when employed as encryption) for it has too small of a output space (repeating patterns will be over a few number of bits), thus it will be possible to attack this with an algorithm to reduce the scratchpad size significantly from the 2MB.
I agree with this. Only a small number of bits of the output of AES are being used, but AES does not guarantee that all of its output bits are random. For example, consider an algorithm AES' which is just like AES except that it appends 10 trailing bits that are always zero (AES'(x) = AES(x) << 10). This would be just as secure as AES for encryption, but catastrophically bad for slow_hash.
I suspect the developers wanted to use AES because of the hardware support in Intel CPUs,
but they made a mistake, though it isn't immediately apparent how catastrophic this is (unlike my toy example above for example). If they used a true secure hash, it would be much slower and likely not memory bound.
The algorithm can and should likely be improved in this regard, although I don't have any immediate suggestions how.
Monero #REKT

"... The reality is community takeovers are garbage. The problem is they are taking over something that is always a scamcoin on one level or another. They have no motivation but cashing out and profit..."