I agree that Bitcoin core has had a lower rate of bugs per lines of code than industry average, but when you increase complexity, and particularly when you increase the number of lines of code, you create defects. It's a hard and fast rule of the software industry, ask anyone (except a Java programmer).
In reality SegWit is cleaning up a lot of technical debt with the transaction format and it's simplifying things for wallets that use it. SegWit simplifies transaction handling complexity by fixing the malleability issue fundamentally, this should reduce defects in all wallets that use it.
I find it very hard to believe that implementing Segwit support in existing software will be easier than a 2MB hard fork, please site a source for this.
SegWit(or a similar transaction format fix) is effectively a prerequisite for any block size increase hard fork due to the
sighash issue. BIP109(Classic) ended up using the same limiter proposed in BIP101 which has issues(it makes testing of some codepaths more difficult for one), funny enough even Gavin
argued against the approach ultimately used in BIP109, they used it anyways after realizing some pools used transactions over 100,000 bytes for payouts. SegWit is also backwards compatible so unlike a hard fork existing software doesn't have to rush code out without a chance to properly test. Rushing and skipping testing/code review is something that certainly increases defects in the software industry.