An attack like this could still be done for CLI clients/library clients such as curl (ie. server-to-server connections), none of which I'm aware of incorporate CT log verification.

You can add CT checks to such software with e.g. ctutlz (a Python library towards this end) but you need to be on the sort of treadmill that browsers are on, with regular updates and disabling security features like CT checking in browsers that don't get updated in a timely fashion.

All the non-Google modern CT logs moved to rolling annual logs. Cloudflare's Nimbus for example, is actually logs named Nimbus2019, Nimbus2020, Nimbus2021 and so on. Nimbus2019 is for certificates that expire in 2019. Most of them are already expired 'cos it's November already, it doesn't see a lot of updates, in January Cloudflare can freeze that and eventually they can decomission it, browsers will stop trusting it, but it won't matter because those certs already expired. If you go get yourself a new Let's Encrypt cert now, it'll probably be logged with Nimbus2020, come January 2021 you won't care if Cloudflare freezes it and starts shutting it down.

As a result you need frequent (say, monthly seems fine) updates to stay on top of new logs being spun up and old ones shutting down, or else you'll get false positives.

For CLI or server software that has a regular update cadence anyway I can see this as a realistic choice, for a lot of other software it'll be tough to do this without more infrastructure support.

But the server can’t do header checks for CLI tools prior to certificate negotiations, so it would be difficult to get away with. Not impossible, but it’d limit your Targets to IPs who are exclusively non CR clients. Any slip up and you’d be busted.