2. Being forked from Bitcoin is a blessing and a curse. Merging bug and security fixes from upstream Bitcoin (which will remain the target of more powerful proving and attack than any altcoin for the foreseeable future) is great, but it is going to be progressively more difficult to do so. The risk is exceedingly great that (as has just happened over the last few days) Bitcoin will reveal a security hole, and a cryptocurrency forked from it will not have implemented the fix.

3. Bitcoin's use of secp256k1 is...ok, but given that SafeCurves (Daniel J. Bernstein and Tanja Lange) view secp256k1 as unsafe, the use of the same curve is a little bit of a risk (Monero uses Curve25519).

In short, the criteria Secp256k1 fails are not generally a concern for us. The curves' recommended by the authors did not exist when Bitcoin was created and might have been preferable.  But The popular curves in widespread use today fail in generally worse ways (e.g. no evidence that they aren't cooked by the NSA) and the curve we use offers very high speed implementations and is safe for our use, even if something else would have allowed simpler implementations.

There are other criteria that the implementations of the recommended curves fail— e.g. it looks like curve25519 requires the most significant bit of the private key is set. Beyond reducing the keyspace this has the effect of making it impossible to use schemes like BIP32 for public derivation of addresses. (At least, while using the standard constant time implementations).  Perhaps more interesting is that the page does not penalize curve25519 for having a non-one cofactor. As mentioned this reduces the rho-hardness, but since failure to handle it correctly has resulted in cryptographic weaknesses (e.g. in PAKE schemes). Cryptographic protocols need to multiply their values by the cofactor it's an implementation trap along the lines of the "completeness" examples and this is easier to get wrong if your cofactor is one as it is in secp256k1.