Complexity costs come from backwards compatibility. Backwards compatibility is essential because otherwise the change potentially confiscates users funds.
Assuming compatibility is required softforks generally reduce complexity because they relax the requirement for synchronization between participants.
Softforks reduce deployment complexity but increase overall complexity.
A softfork is like internet access over phone-lines. If you pick up the line, participants that aren't on the latest code will often hear a bunch of garbage that they can't make sense of. Someone might even send them money but they won't be able to make sense of it or accept it since it's now encapsulated.
From an overall network perspective, this may be a worse state of affairs vs. just making everyone upgrade (hard-fork).
You can't just "make everyone upgrade", not without a time machine-- because there are transactions which may have been written arbitrarily far in the past, already signed, potentially lock-timed, whos signers (or at least their keys) have sailed off into the sunset.
If compatibility with their signatures is dropped those funds will be irreparably and irrecoverably destroyed.
So, for example, BCash deployed an earlier version of our schnorr signature spec (from before the taproot part was finished) in a "hardfork" but preventing destroying funds meant that they had to keep the ECDSA support around (duo to presigned transactions, hardware security modules, etc.) -- so they didn't escape any complexity in that change, they introduced a disruptive flag-day which introduced its own extra complexity.
> often hear a bunch of garbage that they can't make sense of
The changes are compatible so you know those extra fields are stuff "from the future" which you don't understand and know you can ignore.
> but they won't be able to make sense of it or accept
The recipient of funds always specifies their own rules, you'll never specify rules that you don't understand so there isn't any issue with not being able to accept it.
It's not artistry, it's overly complex hackery to satiate some weird technological obsession.
Even with a soft fork, everyone still needs to update their nodes to maintain consensus. BIP100 signalling would have fixed everything and avoided so much drama.
> It's not artistry, it's overly complex hackery to satiate some weird technological obsession.
Also known as... backwards compatibility.
>Even with a soft fork, everyone still needs to update their nodes to maintain consensus
Not really. If you decide to not upgrade your node you're not going to get kicked off the network. Your node won't be enforcing the new rules (which is bad), but you're probably not going to lose money due to herd immunity and/or game theory. Specifically, your client will blindly accept taproot transactions (without checking for them) if they make it into a block. An evil miner could possibly use this to send you fraudulent transfers, however:
1. you need to somehow amass the hashpower necessary to generate such a block. this is non-trivial given the network difficulty
2. the block would be considered invalid by the rest of the network, so you'll be forfeiting the regular block reward of ~6.25 BTC
3. other miners won't build on top of this block, so it will take forever to get to 6 confirms
4. in addition to the above, your fork will get overtaken by the legitimate chain and will be ignored
5. if it turns out that your victim did upgrade his wallet software, you just spent a bunch of resources for nothing.
