It was never presented or intended to be "the solution" and merely a small peice of a puzzle in a comprehensive and holistic approach to addressing Scalability and capacity.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htmlTL;DR: I propose we work immediately towards the segwit 4MB block
soft-fork which increases capacity and scalability, and recent speedups
and incoming relay improvements make segwit a reasonable risk. BIP9
and segwit will also make further improvements easier and faster to
deploy. We’ll continue to set the stage for non-bandwidth-increase-based
scaling, while building additional tools that would make bandwidth
increases safer long term. Further work will prepare Bitcoin for further
increases, which will become possible when justified, while also providing
the groundwork to make them justifiable.
Concurrently, there is a lot of activity ongoing related to
“non-bandwidth” scaling mechanisms. Non-bandwidth scaling mechanisms
are tools like transaction cut-through and bidirectional payment channels
which increase Bitcoin’s capacity and speed using clever smart contracts
rather than increased bandwidth. Critically, these approaches strike right
at the heart of the capacity vs autotomy trade-off, and may allow us to
achieve very high capacity and very high decentralization.
Further out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost.
Finally--at some point the capacity increases from the above may not
be enough. Delivery on relay improvements, segwit fraud proofs, dynamic
block size controls, and other advances in technology will reduce the risk
and therefore controversy around moderate block size increase proposals
(such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will
be able to move forward with these increases when improvements and
understanding render their risks widely acceptable relative to the
risks of not deploying them. 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.