Segwit doesn't give any spammers more power than they have had before, in fact it makes them much weaker.
yes, that's not exactly what I'm trying to illustrate (and concede that I didn't do very well and make it clear)
The problem in my eyes is the widespread perception that Segwit will only be good (in practice) for a ~2.1MB blocksize.
I'm not saying that Multi-sig spam will be more of a threat in it's own right, I did state that the ratio of spam to transactions would simply remain the same. My point is that the spammers would see the opportunity that 1.9 MB of extra space presents to them, with today's single purpose blocks, that cannot be achieved, only a DoS style attack to stuff the blocks with signatures (which would be unambiguously a spam attack). The point about every spam attack we've suffered in single purpose blocks is the same issue with the trolling of discourse on Bitcoin discussion forums: the smartest way to spam is to make it both effective flooding and ambiguous as to whether or not it really is spam. That way, trolls have an easy job of suggesting that those crying foul are actually just paranoid pessimists, as a means to aid prosecuting the "big blocks to handle all this genuine not-spam economic activity" perspective.
Filling 1MB blocks with 15 signer multi-sigs would not be sufficiently ambiguous to achieve that social engineering goal, but getting just enough multi-sig spam to fill unused space in the witness block would constitute the right balance of ambiguity to argue it's not malicious over-burdening of the blockchain; get out of here with your tin-foil hats etc.
It improves the system by changing the limited quantity from "size" to weight because weight better reflects the true costs to the system than size. Size is totally irrelevant for pruning nodes, with fast-block-relay-protocol, BIP152, and Fibre size is almost totally irrelevant. It matters for non-pruned nodes, but at the current size and growth rates those are already effectively pushed out of using cheap fast storage-- e.g. you're not likely to run a node on a 256GB SSD anymore.
e.g. see the stats from Matt's public fibre network:
-- with the exception of small or effectively empty blocks that fit into a single packet, the size of a block has no real effect on its propagation time. (Time figures are in millisecond delay over the speed-of-light time)
Though size is decreasingly important, UTXO impact remains important as we previously ignored in the past limits. Because size is blind to UTOX impact: A spammer could create transactions that bloated the UTXO set and paid _less_ per byte than ordinary transactions.
One possible solution is multiple distinct limits but a problem there is that with multiple limits in play it is impossible for wallets to figure out appropriate fees, because the right fees would depend on the exact mixture of transactions at play when the block is created. Multiple effective limits also make creating an income optimizing block very computationally difficult-- but with one limit you simply take transaction in order of fee per limit-used. So to avoid that the weight limit combines both witness and non-witness (utxo impacting) limits into a single limit. Whenever this is done, improving one factor (e.g. amount of worst case UTXO bloat per byte to typical) will make another worse (e.g. worst case amount of size.). Segwit's parameters were set to massively decrease the amount of UTXO bloat possible while only increasing the worst cast size modestly:
Green line is how many times beyond typical a UTXO Bloat block can be, red line is how many times larger than typical a "size" bloat block can be. X is the segwit factor, which is 0.25 in the actual segwit proposal. The pre-segwit behavior is effectively an X of 1.
Since UTXO costs are much more concerning than size on the modern network it might be arguably to set the segwit factor even lower, but the size bloat goes up hyperbolically with a lower factor. So even though size is less important the trade-off becomes less attractive with values much lower. The value chosen for the proposal also happens to be just about what is required to get virtually all the capacity gain from this particular restructuring, owing to the typical ration of witness to non-witness data in transactions.
e.g. see the stats from Matt's public fibre network:
-- with the exception of small or effectively empty blocks that fit into a single packet, the size of a block has no real effect on its propagation time. (Time figures are in millisecond delay over the speed-of-light time)
Though size is decreasingly important, UTXO impact remains important as we previously ignored in the past limits. Because size is blind to UTOX impact: A spammer could create transactions that bloated the UTXO set and paid _less_ per byte than ordinary transactions.
One possible solution is multiple distinct limits but a problem there is that with multiple limits in play it is impossible for wallets to figure out appropriate fees, because the right fees would depend on the exact mixture of transactions at play when the block is created. Multiple effective limits also make creating an income optimizing block very computationally difficult-- but with one limit you simply take transaction in order of fee per limit-used. So to avoid that the weight limit combines both witness and non-witness (utxo impacting) limits into a single limit. Whenever this is done, improving one factor (e.g. amount of worst case UTXO bloat per byte to typical) will make another worse (e.g. worst case amount of size.). Segwit's parameters were set to massively decrease the amount of UTXO bloat possible while only increasing the worst cast size modestly:
Green line is how many times beyond typical a UTXO Bloat block can be, red line is how many times larger than typical a "size" bloat block can be. X is the segwit factor, which is 0.25 in the actual segwit proposal. The pre-segwit behavior is effectively an X of 1.
Since UTXO costs are much more concerning than size on the modern network it might be arguably to set the segwit factor even lower, but the size bloat goes up hyperbolically with a lower factor. So even though size is less important the trade-off becomes less attractive with values much lower. The value chosen for the proposal also happens to be just about what is required to get virtually all the capacity gain from this particular restructuring, owing to the typical ration of witness to non-witness data in transactions.
Re: bloated blocks aren't an issue; maybe for today's internet. I worry that everyone is assuming that global internet infrastructure can only improve, based on a Pavlovian observation that it has only ever improved. Specific political tensions are beginning to come together that threaten the trend we know and love, it may pass off withut major incident, but I believe that's dangerously optimistic planning.
I don't entirely understand your point about UTXO set bloating. Surely the UTXO set is defined by confirmed transactions, and so a direct relationship between block size and UTXO set does exist? Are you saying that because the UTXO set is only tx data and not signature data, that a different attack exists, whereby transactions with a high txdata:sigdata needs to mitigated?
I can see how limiting the power to bloat UTXO data would be the solution, but the way that the block weight designation mitigates that is not totally clear....
Also (a broader point) why is UTXO bloating such an issue, you mention that it's more serious than block bloating attacks, but I'm not grasping why. Does limiting tx data to a hard 1MB limit prevent an unmanageable amount of tx data-heavy from DoS'ing available RAM in Bitcoin nodes?
(JOKE ALERT). I'll respond a little later, I may just read it all a 3rd time before I do. 
