It's all my opinion, of course. I'm not aware of any objective way to evaluate these sorts of design techniques, and if you're looking for proof, you'll have to look elsewhere. (But ask yourself what proof you have for any design technique you hold dear.)

Here's a brief rationale for each one.

Important and popular:

- Refactoring: Allows you to improve design as you learn.

- TDD: Significantly reduces programmer error.

- Closures + first-class functions: Enables new design abstractions which reduce duplication.

- Domain-driven design: Nothing really new here, but it's a useful way to describe OO design that's finally making an impact on the legions of people who programmed procedurally in an OO language.

Important but not popular:

- Evolutionary design: The only technique I've seen that actually improves code quality over the long term. See also http://martinfowler.com/ieeeSoftware/continuousDesign.pdf (PDF)

- Refactoring beyond what's built into IDEs: Most people I meet don't significantly improve the design of their software when they refactor. Instead, when they need big improvements, they rewrite (and call it "refactoring"). I think that's because they don't really understand refactoring, which involves a series of small, behavior-preserving steps, most of which are not automated by IDEs.

- Domain and business expertise: Provides context for trade-off decisions.

- Conway's Law: I see the most defects and productivity problems at the boundaries between teams. This makes team structure an architectural question as well as a political question. When you have a large system, how do you break it into parts and who works on what? A careless approach results in a lot of cross-team communication, which leads to performance problems and defects.

- Minimizing maintenance costs: Most software spends more time in maintenance than in initial development. See also http://jamesshore.com/Articles/Quality-With-a-Name.html

Popular but long-term pain:

- DSLs: Suffer the same problems that frameworks do, but worse: When your needs diverge from the solution offered, you have to hack in kludgey workarounds. They suffer from leaky abstractions, so when they don't work right, it's time-consuming and difficult to figure out what's wrong. You're locked into their syntax, so switching to an alternate approach is difficult at best and requires a rewrite at worst.

- BDD: Started out as "TDD with different words" and became steadily more obsessed with automated english-language specifications, which adds cost over TDD without adding significant value. The hope that business users will read (let alone write) a BDD specification is a pipe dream in nearly all cases, and programmers are perfectly capable of reading well-written code--which has the additional benefit of being more precise than english. The "fluent" interface many BDD frameworks use suffer all the DSL problems I just mentioned. External DSLs like Cucumber gravitate towards slow and fragile end-to-end tests (see next item) and also don't play well with refactoring tools, which is a maintenance problem.

- Acceptance test-driven development: http://jamesshore.com/Blog/The-Problems-With-Acceptance-Test...