If there are SPV clients that don't pay attention to versions in block headers, then setting the block version negative doesn't directly help them, they will ignore it in any case.

If the worry is full nodes that are not upgraded, then a block with a negative version number will, indeed, fork them off the the chain, in exactly the same way a block with new hard-forking consensus rules would. And with the same consequences (if there is any hashpower not paying attention, then a worthless minority chain might continue on with the old rules).

If the worry is not-upgraded SPV clients connecting to the old, not-upgraded full nodes, I don't see how this proposed BIP helps.

I think a much better idea than this proposed BIP would be a BIP that recommends that SPV clients to pay attention to block version numbers in the headers that they download, and warn if there is a soft OR hard fork that they don't know about.

It is also a very good idea for SPV clients to pay attention to timestamps in the block headers that the receive, and to warn if blocks were generated either much slower or faster than statistically likely. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in general.