Its wrong to say that a hard fork occurs when there are 2 versions of the blockchain. That situations also occurs in a soft fork. The actual difference between a hard fork and a soft fork is determined by the ability of the nodes on the main chain to validate blocks that are produced in accordance with the consensus rule of the fork.
Soft forks don't lead to a blockchain split, otherwise the SegWit activation would have lead to an alternative blockchain. SegWit transactions still look valid to legacy nodes, it's just that legacy nodes lack the ability to properly interpret them under the new rules that the soft fork brings with it. Now if you were to disable SegWit again -- ie. have a signifcant number of nodes handle SegWit transactions like legacy nodes -- that then would require a hard fork, since SegWit nodes would deem such transactions as invalid while legacy nodes would process them, leading to a chain split.
In short: Soft forks only require a hard fork (ie. blockchain split) when rolling back the change, not when first deploying the update. Not requiring a blockchain split on deployment / activation is pretty much the definition of a soft fork.