Ted makes the point that
your code is as good as your team, meaning that if your team isn't up on the techniques you're using, they'll soon disappear from the code, and you'll lose any benefits. Interesting reading that and noticing a discussion about
continuations in Tcl.
There's no absolutes when it comes to what techniques you should use in your program, its far too dependent on the situation. Advanced techniques can often buy you a lot in terms of power and expressiveness, which is a win. Improving your team (as Ted suggests) is sometimes needed to take advantage of that. Other things being equal, a better team is usually a good thing (and almost always a more interesting thing).
Of course, in any real situation, you have to balance that against the costs of acquiring new people (will your project require superstars?), getting new people on board, mental overhead of too many choices vs. proficiency in fewer, etc. Is your team more interested in learning in the area of programming techniques, or would they rather spend more time learning other things that are also relevant? What kind of bang for the buck do the techniques bring to your particular project (big gain or incremental)? The tradeoffs can be worth it in some situations but not others.
(About continuations in Tcl... for a language that has so many ways to capture state, where you don't tend to do the type of development that often could benefit from them, where a strength is attracting people without compsci backgrounds, and where a clean, simple and powerful event model is in place which obviates many of the common scenarios for using continuations by virtue of how programs are normally structured... well, lets say the benefits are far more likely to be on the incremental side, with substantial costs. But again, everything depends on the particular situation.)
