Ignoring the miners long term incentives to benefit the ecosystem and assuming short term selfish behavior only, the miners will be incentivized by more tx fees when the capacity more than doubles. When margins are extremely tight these incentives are more than enough to encourage the right behavior.
You seem to be assuming that the "fee market" will set in and space in blocks will be a scarce resource. But, if a sizable fraction of the traffic adopts SW, the fee market will be delayed by another 2 years at least. Large junk traffic generators like SatoshiDice can avoid paying higher fees by using the SW format, while miners and full non-mining nodes will see their bandwidth demands increase beyond the 1 MB mark, just as if the block size limit had been raised to 4 MB right now.
I don't pretend to assume how quickly bitcoin will scale, although I would rather have better optimised solutions like SW vs BIP101 to address capacity with a list of backstop hardfork options for last minute solutions in un-expected growth spurts -
In Bitcoin Core we should keep patches
ready to implement them as the need and the will arises, to keep the
basic software engineering from being the limiting factor.
I believe it is quite likely capacity demand won't increase as quickly as some suggest as people are naturally resistant to trusting new and volatile currencies but in cases where this isn't true than having a slight delay in confirmations while a pretested hardfork is deployed isn't the end of the world. (Paypal and visa go down all the time after all and chaos doesn't ensue)
Large junk traffic generators like SatoshiDice can avoid paying higher fees by using the SW format, while miners and full non-mining nodes will see their bandwidth demands increase beyond the 1 MB mark
Lite wallets and SPV nodes will be upgraded automatically to take full advantage of SW and users will naturally upgrade without much thought. SatoshiDice will be constrained to compete with everyone else and have no advantages.
just as if the block size limit had been raised to 4 MB right now.
This is false as the average load for 100% full blocks would be around 2MB with only approaching short of 4MB for heavy multisig.
There are other technical nuances that benefit full nodes with SW such as-
Existing full nodes already do not validate signatures in the far past-- with SW they could also skip transferring them among other benefits .
Here is an example if you have any doubts as to why you are incorrect-
Yea, the exact impact depend on usage patterns.
If your case is a counting one input, one output, pay to hash transactions the sizes work out to
4 (version) + 1 (vin count) + 32 (input id) + 4 (input index) + 4 (sequence no) + 1 (sig len) + 0 (sig) + 1 (output count) + 1 (output len) + 36 + (32 byte witness program hash, push overhead, OP_SEGWIT) + 8 (value) + 4 (nlocktime) = 96 non-witness bytes
1 (witness program length) + 1 (witness program type) + 33 (pubkey) + 1 (checksig) + 1 (witness length) + 73 (signature) = 110.
96x + 0.25*110x = 1000000; x = 8097 or 13.5 TPS for 600 second blocks; (this is without the code in front of me, so I may well have slightly miscounted an overhead; but it's roughly that)... which is around double if you were assuming 7 tps as your baseline. Which is why I said double the capacity in my post... but YMMV.