Networking's version of the border security officer. Show me your ID!
NAC (802.1X with EAP-TLS) becomes that security officer. And like the ones at border crossings, they seldom have a sense of humour. Their job is to keep the riff raff out! If a device cannot produce a valid certificate signed by the PKI the security officer checks for, your device does not get on the network. Period!
Let's assume for a moment that all your printers (even the really old ones) can take a certificate and that the process can be automated so it's not weeks of effort for each renewal. Let's pretend that all the IoT devices you operate enjoy being recipients of certificates, and that you have a fantastic way to manage those. Let's even grant that all of your medical devices, building controls and video surveillance systems are compatible. That's fantastic, this is a solid way to ensure no rogue devices on your network!
The reality though, is that most organizations must plan around exceptions. And in the midst of deploying all this, the easy solution is "MAC filter" those devices that can't or just won't take a certificate. So now, your high security project just reduced itself to the lowest common denominator, re-introducing the possibility of MAC spoofing. So was the whole project worth your time? That's a business decision.
Say you go forward, accepting that your residual MAC spoofing exposure now lives in an exception list that only grows. Now you really need to understand that a PKI outage includes a full Network Outage and that the network access you were counting on to fix PKI is also gone. I'm not trying to discourage you. I've been at the receiving end of someone plugging into an open port and showing us all our dirty little secrets (phew it was a pen tester). I'm just trying to make sure you treat this as a full PKI project (not a network project) and that you plan the failure modes before the rollout instead of during an outage.