The safecurves site is substantially advertising material for the deservedly well regarded curve25519/ed25519 family curves with a rather one sided presentation. Some of the criteria it names are largely or completely irrelevant for some applications, others are essentially duplicates of each other, while it omits criteria that ed25519 fails which have resulted in serious vulnerabilities many times.
Secp256k1 admits an efficient endomorphism that can be used to make operations a fair bit faster. Attacks are among the things it makes faster: the presence of the endomorphism reduces security by about 0.8 bits. However, secp256k1 has a bigger group size than some other popular '256 bit' curves. For example, secp256k1 has about 1.2 bits higher discrete log security than ed25519 even considering the endomorphism.
The currently conjectured discrete log security for all reasonable 256 bits curves is high enough that small differences probably do not matter, so it would be more interesting to think about security in terms of 'unknown attacks' unfortunately it isn't really easy to do much there. One might guess that the fact that secp256k1 is j-invariant zero might admit some future attack but it could just as well prevent some future attack.
One clearly positive security property of secp256k1 is that it doesn't have a cofactor. The presence of a cofactor and the incomplete handling of it resulted in many vulnerabilities in various protocols (PAKEs, ZKPs, traceable ring signatures), including a total break in Monero family cryptocurrencies. The safecurves "Completeness" and "ladders" criteria both indirectly require the presence of a cofactor but it never mentions this trade-off, so I think this is the best example of how that resource is best considered marketing copy rather than an earnest attempt at scholarship.
Arguments that its somewhat more complex to write constant time code for secp256k1 than ed25519 seem pretty subjective to me: Many ed25519 implementations fail to be constant time, and constant time code exists for secp256k1. At the end of the day using naively written low level cryptographic primitives is a bad idea regardless of the curve, and if you're using well developed code this isn't an issue. Similarly, abstract claims about performance don't really matter: for performance what matters is how things benchmark out in actual applications. To the extent that applications use variable time operations for performance reasons in at least some functions the same applies to all curves, if not in their group law in their exponentiation algorithm.