From a security standpoint, would it be considered bad practice to use e.g. the curve secp256r1 in our TLS1.2 settings
As of October 2021, NIST P-256 (secp256r1) is considered to be more than secure enough for use in TLS in any environment. Complaints about NSA backdoors relating to elliptic curves are mostly due to Dual_EC_DRBG, which is a technically separate matter, although from a security policy perspective it remains relevant.
Some loose reports have indicated that NSA implemented backdoors to some NIST elliptic curves. As far as I understand these do not include P-256, P-384, etc.
This is sort of correct. The secp256r1 curve in TLS 1.2 is being used for the Elliptic Curve Diffie-Hellman (ECDH) exchange. This is the part of the handshake that allows the two clients to agree upon a key. There is no strong evidence that the NIST P-256 and P-521 curves were backdoored.
The link you posted is talking about Dual_EC_DRBG. This is a random number generator (CSPRNG) that was backdoored by the NSA. It uses elliptic curves, but has nothing to do with the P-256 or P-521 curves. The use of Dual_EC_DRBG is not specified as part of a TLS cipher suite. It was promoted for use in some TLS implementations, but it is not used today. Elliptic curve cryptography is an entire branch of study based on an entire field of mathematics - the use of EC in a backdoored cipher has no real impact on the security of EC curves or EC cryptography in general.
The reason that people are somewhat suspicious of the NIST curves is because the NSA used NIST to promote Dual_EC_DRBG. Whether or not they were willing participants remains to be seen, and it is worth keeping in mind that the NSA's project to promote this backdoored CSPRNG largely took place between 1997 and 2005. Given general changes in attitudes and policy regarding cryptography and security infrastructure since then, it is certainly not unfathomable that the NSA may have learned their lesson with regard to damaging trust in NIST. It's also entirely possible that they didn't, of course.
Since the NIST curves were derived from random numbers, there's no way to tell if those numbers were picked in order to insert a backdoor. There's absolutely no evidence or cryptanalysis to concretely support allegations of a backdoor, but it does make some people uneasy. Most cryptographers prefer the use of nothing-up-my-sleeve numbers to alleviate this problem.
secp256k1 is a somewhat popular alternative to secp256r1 precisely because its selection process was fairly transparent. Another curve that some people prefer is Curve25519, which is called X25519 when used in Diffie-Hellman, although it's worth being aware that the most referenced resource for evaluating curve security was written by DJB, who developed Curve25519, so it's hardly surprising that he gives it a glowing review. Still, it's well-trusted, and support for this curve is mandatory in TLS 1.3.
Ultimately, this isn't really a question of cryptographic strength. It's a question of perception and gut feelings around who is or is not trustworthy. There's also the question of whether it really matters in practice. If your threat model doesn't include the NSA (which it almost certainly shouldn't - see Mickens' This World Of Ours for an excellent and highly amusing discussion on this topic) then it doesn't make any material difference whether you use secp256r1, secp256k1, or X25519 for your ECDH key exchange in TLS. If the NSA isn't trying to steal your traffic, the secret presence of an NSA backdoor in NIST P-256 is ultimately irrelevant to your threat model. If the NSA is trying to steal your network traffic, in particular, for whatever unfathomable reason, your use of one particular elliptic curve over the other is not going to be an impediment to them.
In fact, the use of TLS 1.2 instead of TLS 1.3 is far more likely to be the source of a practically exploitable vulnerability than a possible backdoor that might allow the NSA to decrypt TLS traffic to your website. Time spent worrying about which EC curve to use is time you could be spending on security controls to mitigate far more likely and impactful security issues.