You've raised some interesting points, and the discussion so far has been fruitful. I'd like to summarize the points raised up to now (please correct me if I missed/misunderstood something):
@imontalvo: lack of developers, licensing, funding, the programming language and the software architecture. In addition, Idel highlights testability, scalability, task-division across developers and the use of the Object-Oriented architecture.
@eladsal identified as key issues licensing, stability, speed, portability, ease of use, integration with other languages and maintenance. Starting point in roadmap: get/set for all data.
@markwilson highlights the free GUI, speed, stability and the existence of a profitable business model
@kobusvanzyl highlights efficiency and considers the benefits of OO.
A lot of issues have been raised, and I also agree we need a roadmap, as @samhatchett has pointed out. I also agree we should prioritize in accordance to our (limited) resources.
Bug-Fixes (short-term): For the short-term, we need to release EPANET version 2.01.00. This would be an important milestone and should include the most important bug-fixes plus some additional new functions. This goal should be feasible to be achieved (tested/verified) within the next months. The community is waiting for this update (myself included).
Modular Architecture (long term): EPANET 3.00.00 however might be something completely different. There are some other successful examples, such as the QGIS, in which the community  has decided to follow a modular architecture with multiple libraries and with clear APIs which allow the communication of various plugins (written in C++ or Python). As I understand it, the big challenge would be to design and implement the backend, that would orchestrate the different modules. However, I can easily visualize a new software (in any language), which would coordinate the execution of various libraries (all the previous versions of EPANET, the new ones, as well as plugins). Plugin writters (e.g. PhD Students) should have an API which they can use to make their software communicate with the system. Language again should not be extremely important, because I expect wrappers would be created by the community, to assist programs written in any language. Furthermore, I can also visualize having a configuration file in which one can easily select between different models (e.g. Demand-driven, Pressure-driven).
Learn from others: I would also recommend we study/hear how other people in the community have tried to solve the problem, e.g. CWSNet (@zkapelan) , OOTEN (@kobusvanzyl) and others. A webinar could be easy to organize
Collect Data: We need more data for our decisions, and we need to involve as many people as possible. The scientific approach would be to organize a questionnaire, to learn how people are using EPANET. A short/well-structured questionnaire could be easily forwarded to all the members of the community (which are not that many), and it would help us get an understanding of the needs (e.g. in academia and hopefully the industry). It could also trigger the sense of participation and contribution.
Speed (vs?) Modularity: I think there might be a compromise in speed. By making EPANET ultra-fast (e.g. EPANET running on GPUs), we may not be able to make it ultra-modular (as QGIS is). However, what do we mean by "fast", is arbitrary. In any case, identifying the bottlenecks and fixing them it might be a research topic by itself, which may be (hopefully) solvable by writing a plug-in.
Special Interest groups: One idea is to involve researchers from within the same field, and ask them to prepare a joint paper e.g. on water quality modelling in EPANET (what is the state-of-art etc, what the priorities should be etc). This should provide the basis for a road map at least from the scientific point of view.