SegWit does fix that bug and it probably works as intended.

There is one technical objection to it, even if not overriding: it is not a clean solution, but a "clever" (read: ugly and convoluted) "hack", way more complicated than it should be. It makes the protocol itself a bit more complicated -- hence a bit more difficult to learn, maintain, and work with. For one thing, the hack lets old clients think that some coins can be spent without signatures, whereas clients who have upgraded to SegWit know that the signature requirement is in an "extension record" appended to the transaction record (and to each block), which older clients do not see.

The reason why Core chose this complicated solution is that they wanted to avoid a hard fork at all costs.

And the reason why Core hates hard forks is that, if they were to allow one, there would be no excuse to not lift the bock size limit at the same time (basically 2 lines of code).

And the reason why Core absolutely wants to keep the 1 MB limit is that Greg still hopes to see his "fee market" stabilize, and raising the limit would postpone that goal by years. (The "fee market" still gives no signs of stabilizing, even after 18 months. Those who understand the basics of network theory, like Mike Hearn, tried to explain why it can't ever stabilize; but Greg won't listen..)

Another technical objection is that, because of the large number of lines of code that it affects (in the Core client and in all software out there), it creates a non-trivial risk of bugs. It has been extensively tested, but one never knows.

An economic objection is that it changes the way transaction size is measured: data in that extension record are counted at 1/4 of its true size. Thus, a transaction with 200 bytes of normal data and 200 bytes of extension data is considered to have only 250 bytes of "pseudo-size" . This change affects both (a) the packing of transaction into blocks (since it will be the sum of pseudo-sizes that cannot exceed 1 MB) and (b) the transaction fees (since the transactions will be ordered by fee divided by pseudo-size, rather than size, when assembling a block).

This change affects the "consensus rules" that say when a block is valid, but in a way that still makes the change a soft fork rather than a hard fork. Because of (a), miners will have to use the pseud-size when deciding how many transactions they can put into a block. But then (b) is practically mandatory, because it maximizes their expected fee revenue from the next block.

There is no technical or economic justification for this size-counting change. Apparently Core added it to SegWit in order to provide an incentive for for people to actually adopt SegWit -- that is, to actually issue transactions with signatures segregated as it allows. For miners and relays, the extension records costs pretty much the same as the normal part. The extension part must be handled, checked, transmitted and stored by all miners and relay nodes, except by simple clients who do not want to verify other peopl's signatures in the blockchain.

The main objection to SegWit is political. Core tries to claim that, with the new way of counting sizes, SegWit will let ~70% more transactions fit into the 1 MB limit. Therefore, Core argues, there is no need to even discuss a real block size increase until SegWit is activated and is being used by everybody. Which of course is unacceptable to the big-blockers, who want a real increase so that the network becomes uncongested again -- or, at least, requires much lower fees.

Thus, I would guess that Core is dead set on SegWit (even at the cost of magnifyig the Size War) because it is a way to block any real size limit increase, that could postpone the dreamed-of success of the "fee market". And many big-blockians oppose it for that reason too.

Another objection that can be made against SegWit is that is is not really necessary, and does not deserve the priority that it got from Core (to the point of being included in the Core release in a short time, in spite of all the controversy around it). A transaction can be "malleated" by a hostile agent only after it has been broadcast or shared with someone else, and before it is included in the blockchain. Many applications that need to worry about such attacks can easily prevent it by using some other method to identify unconfirmed transactions.

The bug is worrisome mainly for chained unconfirmed transactions: if client C2 issues T2 that spends the output of T1 before T1 is confirmed, it could happen that a malicious agent malleates T1 into T1m, and T1m gets confirmed instead of T1. Then T2 would fail, and the client C2 would have to issue it again. But such chains are problematic anyway, because the client C1 who issued T1 himself could issue a double-spend T1d, which could get confirmed instead of T1.

Fixing the malleability bug is said to be essential for the LN. Yet that is not clear; I have seen claims to the contrary. Anyway the LN has not reached the vaporware stage yet, so that cannot be an excuse to push SegWit with such urgency. And the bug could be fixed in a much simpler way with a hard fork...