Many in the anti-spam faction have contemplated running a pre-SegWit node. But they're told that it is an insecure downgrade and a detrimental idea. So,
Is it safe to assume that Bitcoin is not soft-fork backward compatible?
The only benefit of a soft fork over say a hard fork is that old nodes aren't forked off the network if they fail to validate all the consensus rules. In the case of a hard fork (a relaxation of the consensus rules) an old node could reject a valid block and then be stuck forever because other blocks would be mined on top of that block.
What are the technical risks to the security of individual pre-Segwit node runner?
If you don't check all the consensus rules (including all soft fork rules that have been activated) then you risk accepting an invalid transaction or invalid block. If the majority of other full nodes and other miners are enforcing these rules it shouldn't be a big deal. You'll end up later following the chain with most proof-of-work (PoW) and discarding the block you initially thought was valid but turned out to be invalid. But you are in a stronger position if you don't rely on others and validate all the consensus rules yourself.
What are the detrimental effects to Bitcoin as a whole if hypothetically majority nodes switched back to non-Segwit version of nodes?
If the majority of full nodes and miners didn't enforce all the consensus rules there is a much higher risk of an invalid block being accepted by the network for a longer period of time resulting in larger re-orgs and more confusion on the latest state of the blockchain. In an extreme case miners could continue mining on top of an invalid block forever and then it wouldn't be clear what consensus rules were being enforced and which weren't. The entire system breaks down if full nodes and miners aren't sure what the consensus rules are and which consensus rules should be enforced. If a few full nodes don't want to enforce all the rules it isn't a big problem. If the entire network doesn't want to enforce all the rules it starts to become a much bigger problem.
In addition to Michael's excellent answer, Bitcoin Core v12.1 doesn't include many performance improvements added over the years. Block verification is about twice as slow compared to v25.0 (according to Jameson Lopp's benchmark data) and it doesn't have compact block relay. Too many nodes running versions this old would significantly increase the rate of stale blocks which causes miner centralization pressure.
EDIT: Murch suggests in his answer that slow nodes wouldn't actually negatively impact the rest of the network, so be sure to give that a read.
Pre-segwit nodes consider segwit transactions non-standard and will not accept them to their mempool and therefore also not forward them. They would only participate in relay of unconfirmed non-segwit transactions. At this time, about 94% of transactions use at least one segwit input.
Therefore, pre-segwit nodes would see a small fraction of unconfirmed transactions. This would potentially reduce the bandwidth-use of such a node, since segwit peers would also not forward unconfirmed segwit transactions. Segwit is backward- and forward-compatible in the sense that pre-segwit nodes would still process the most-work blockchain, since they would assess segwit transactions as valid even while non-standard, and arrive at the same chainstate. They would however be incapable of assessing validity of segwit transactions and be essentially relegated to blindly trusting that the most-work chain is in fact valid due to not processing witness data. This would open pre-segwit nodes up to accepting a chain of invalid blocks designed to enable doublespend attacks on such nodes. A pre-segwit node may also have significantly skewed feerate estimation, due to seeing such a small portion of the queuing unconfirmed transactions.
Bitcoin Core 0.12.1 was released in November 2016 and has been end-of-life since late 2017. Beside all the performance improvements in the last 7 years, also fixes to security issues discovered in the project that may affect that release have not been backported. It is unclear what benefits a user might expect running a client this old. If the motivation is the bandwidth-use reduction, they could achieve the same and more by running in -blocksonly mode with a maintained version. If they explicitly want to only relay legacy transactions, I suspect that a small patch could change a node’s behavior that would make the node present itself as a non-segwit node without actually downgrading to unmaintained software.
Nodes that don’t participate in the relay of unconfirmed transactions would generally be slower in propagating new blocks since they would not be able to make use of compact block relay. Bitcoin Core’s peer manager protects a few of its peers from eviction by merit of that peer having been the first to offer a new block lately. I suspect that even if a super-majority of nodes (e.g. 90%) switched to pretense non-segwit behavior, the remaining nodes would form a well-connected compact-block-relay backbone that would be hardly affected at all.
My suspicion would be that any users running either the outdated node software, or a pretense non-segwit node would mostly downgrade their own experience without affecting other nodes much.
If miners downgraded to only mining non-segwit transactions, they would pick from a smaller pool of unconfirmed transactions while passing on the higher feerate segwit transactions in the mempool. This would lead to their own block-rewards being reduced to the benefit of miners that do not participate.
Overall, I do not see any benefits to this idea beyond it perhaps giving the adopter a fuzzy feeling of doing something, and since all the downsides apply to the adopters themselves, I wouldn’t worry whatsoever if I saw some people implement it.
