Yes, these are implementation specific problems. I think the article wasn't saying "just use ECC instead", it was saying "use ECC instead because it has a wide

Yes, these are implementation specific problems. I think the article wasn't saying "just use ECC instead", it was saying "use ECC instead because it has a widely recognized and standardized implementation path that's proven secure, in contrast to RSA." The biggest issue he describes is that, when implementing RSA, most of the parameter choices are necessarily private to the developer, meaning the dev is expected to supply good parameters on her own, when "good" means in terms of heavy math that no non-cryptographer can be expected to know. It's not just key size--there's a bunch of bad choices a dev can make, many of which are hard to recognize as bad choices. Secondarily, many of those bad choices are driven by implementing RSA in constrained environments, where they're a tradeoff to achieve performance goals--so known-good techniques or algorithms are actually rejected. ECC, by contrast, is almost all public parameters, so the security community can provide (and already has) known-good parameters that are provably secure, and a dev can simply choose a known-good configuration for their implementation to go with a well-regarded library like libsodium.