It's probably a pretty bad idea to use it unless you must and you really know what you're doing... however.
Of course. And I agree, that it is a bad idea. But it is possible (and valid by consensus, which means, that there is some room for future attacks). And: if anyone can get a raw private key, then knowing the tweaked key is not needed at all, to move the coins (so, closing eyes, and saying "we are safe, because everything is always tweaked" is wrong, because consensus rules don't check it). Which also means, that each Taproot address is as strong, as this untweaked key is, as long as spending by key is possible (so, you can import raw, untweaked version to a different wallet, and move the coins, without knowing, how exactly the key was tweaked; the private key to the untweaked version is the only consensus-checked thing).
Which also means, that there is not that much difference between "<pubkey> OP_CHECKSIG" security, and Taproot address security. The main improvements are related to signature checking, because Schnorr signatures are used instead of ECDSA legacy versions. But from secp256k1 point of view, if you know some private key for P2PK, then you can move coins from a related Taproot address as well. So, if secp256k1 will ever be broken, then both, P2PK and P2TR, will be broken in a similar way.
By the way: tweaking P2PK public keys is also possible. The main reason why it is not widely used, is because these things were discovered later, and there are too many untweaked P2PK public keys, to introduce it now. But technically, blocking untweaked Taproot keys from being spent, is not that much different, than blocking untweaked P2PK keys; the main difference is "the default implementation" and "historical context", everything else is pretty much equivalent.
And it lies in a similar category, as "blocking non-HD keys", because "tweaked keys" and "HD-keys" are similar: you have just regular public keys, and all of that tweaking is just implementation-defined: consensus never enforces any of that. As well as consensus never enforces deterministic signatures.
Which means, that "keys are always tweaked, so we are safe" is comparable to saying, that "HD wallets are used, so we don't have to worry about randomly generated keys". Because there are many ways to tweak keys: what you can read in BIPs is just an example, and not something, which is checked by consensus rules. So, if instead of SHA-256("TapTweak") you would use SHA-256("Hello World"), then it would work in a similar way, because it is never enforced anywhere.