I wonder if Waterfall methodology still valuable. I see many companies that apply CMMI L2 is just using waterfall. Is it consistent to be a small business and still work with strict Waterfall?

I think many companies are comfortable using waterfall as the artifacts required are classic and generally simpler. One complete requirements document with some revisions based on limited number of change requests. I hope we can move the software industry to use iterative methodologies to increase work progress visibility.

Read more details about waterfall and iterative methodologies at:
Iterative and incremental development
Waterfall model

[Wikipedia quotation]

In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows:

• Many software projects must be open to change due to external factors; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases.
• Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase “following” it. That is, feedback from following phases is needed to complete “preceding” phases satisfactorily. For example, the design phase may need feedback from the implementation phase to identify problem design areas. The counter-argument for the waterfall model is that experienced designers may have worked on similar systems before, and so may be able to accurately predict problem areas without time spent prototyping and implementing.
• Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Constant “prototype design” work is needed to ensure that requirements are non-contradictory and possible to fulfill; constant implementation is needed to find problem areas and inform the design process; constant integration and verification of the implemented code is necessary to ensure that implementation remains on track. The counter-argument for the waterfall model here is that constant implementation and testing to validate the design and requirements is only needed if the introduction of bugs is likely to be a problem. Users of the waterfall model may argue that if designers (et cetera) follow a disciplined process and do not make mistakes that there is no need for constant work in subsequent phases to validate the preceding phases.
• Frequent incremental builds (following the “release early, release often” philosophy) are often needed to build confidence for a software production team and their client.
• It is difficult to estimate time and cost for each phase of the development process without doing some “recon” work in that phase, unless those estimating time and cost are highly experienced with the type of software product in question.
• The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.
• Only a certain number of team members will be qualified for each phase; thus to have “code monkeys” who are only useful for implementation work do nothing while designers “perfect” the design is a waste of resources. A counter-argument to this is that “multiskilled” software engineers should be hired over “specialized” staff.