> Sorry if this is a stupid question, but why not both?
By both you mean, SegWit + Bigger blocks?
It's not possible today to raise the blocksize without exponentially increasing the computing resources required to run a Bitcoin node. So it's not a parameter that can be easily tweaked without drastic consequences.
Also, increasing the blocksize requires what's called a hardfork. That's a backwards incompatible change. Anyone who hasn't updated their Bitcoin software will be left in the dust, and potentially dangerously so.
SegWit, on the other hand, raises the effective blocksize to 2MB, patches a bunch of issues, and provides a means to safely enable off-chain transactions on top of Bitcoin. It does all this as a soft fork; backwards compatible.
That doesn't mean a blocksize increase isn't appropriate; it needs to happen at some point. But because hardforking is so disruptive, it would be best to roll in other breaking changes while we're at it. We should have a solution to the exponential computation issue, and we should have a mechanism to increase blocksize again in the future without another hardfork. Those are hard problems to solve that will take time. SegWit was meant to be a stop-gap.
All that said, I'm not personally opposed to the idea of a more immediate hardfork, ala SegWit2X. I don't think it's the _best_ idea, and I think the hardfork should happen at least 12 months down the road, not 3 months as SegWit2X plans, but the perfect is the enemy of the good. The big issue with SegWit2X is that the developers working on it are not competent for the task at hand, and it's being pushed by parties with perverse incentives.