This is not what the check is used for in these ERCs (see ERC-721, ERC-1155).
The logic they specify is roughly this: when an asset is transferred to a recipient that has code, invoke recipient.onReceived(...), which must succeed and return a specific magic value, otherwise the transfer is reverted.
The purpose is not to prevent smart contracts from owning the asset, but to prevent errors where the asset is transferred to the wrong contract with no way to recover it. This is an error that happens a lot, so many developers consider this an important feature. Smart contract wallets are supposed to implement onReceived (and they do, see for example Safe).
It’s also used to allow a recipient contract to react to a transfer and do something with the asset as soon as it’s received.
We can debate whether these are good design patterns or not, but I think they are at least legitimate and don’t conflict with the AA roadmap (unlike patterns that force the use of EOAs). The fact is that what is arguably the second most important ERC used on the network relies on this ability and the specification can’t be changed.
So are we okay with ERC-721 being unimplementable on EOF(v1)? My assumption is that we want EOF to become the standard way to deploy new contracts, if so this should be addressed.
It would be enough to add an opcode to check if an account has code set (or to change the semantics of EXTCODESIZE on EOF to return 0/1, but I assume that’s not a good idea). Granular code introspection is not necessary.