The way to think about neutrality is asking the question "does this change result in anyone who is currently using Bitcoin to be unable to continue to use Bitcoin in that way?" "Effect" can be making scripts previously spendable no longer spendable (i.e. confiscation), or breaking some protocol utilizing that functionality (e.g. if something were to break lightning). Obviously any change to script or transaction construction can potentially cause those, so careful analysis must be done in order to determine whether those effects may be realized. When we look at historical examples, we can see that each of them did not have any effect on anyone that was using Bitcoin already.
In the famous historical example of disabling OP_CAT and other opcodes, we can observe that none of those opcodes were in use on chain and that no one was proposing to use them. This also had the rationale of fixing an active vulnerability that could cause nodes to crash.
Soft forks that enable new functionality through the use of OP_NOP opcodes likewise used opcodes for which no one was actively using, because they had specifically be designed as upgrade methods.
The same applies with P2SH, Segwit, and P2TR as they redefined script patterns for a different usage. Those script patterns were unused (except for testing and experimentation) hence those upgrades were neutral.
Conversely, in the case of BIP 110, we can see that it is explicitly breaking people who are currently using Bitcoin. As a simple example, BIP 379 Miniscript describes how the opcodes OP_IF and OP_NOTIF can be used in a composable script in order to perform various spendability checks. The usage of such opcodes is further dependent on the sub-expressions. As BIP 110 disallows the usage of OP_IF and OP_NOTIF, anyone currently using Miniscript is at risk of being affected. A miniscript as simple as andor(pk(B),older(1000),pk(A)) (either sign with key A, or sign with key B after 1000 blocks) uses OP_NOTIF and UTXOs created to this policy after BIP 110's activation would be unspendable.
It is conceivable that someone somewhere is already using a policy like this, and activation of BIP 110 would immediately break them - they would have to change how they receive new coins in order to be able to spend their coins at while the restriction is active.
What further exacerbates this is that the scripts themselves are not visible, so the usage of the opcodes in question is not known until UTXOs are spent, and even then, with taproot, only one leaf script is revealed. This makes analysis of who might be affected much harder.
