If you know the disadvantages of macros, then why ask the question? Macros don't respect scope and type. This is an invitation for hidden bugs. Sure, if you are careful, you can avoid them. Same thing with a motor bike helmet Template just lets you detect the most common macro errors at compile-time, rather than at run-time.
Pedantic type checking clutters my code and is really too verbose for me. File, Rank, Piece, Color, Square are all ints in my engine. I am not that paranoid about it because one can make more mistakes dealing with c++ details than passing the wrong type of parameter in chess programming.
It's my belief & experience that raw engine performance might suffer a bit when relying heavily on STL algorithms and containers. This penalty can be as large as 10%, perhaps even 20%. But not more than that, as long as you don't spam the heap and create deep class hierarchies. The reason for the algorithms overhead is not the innate slowness of C++, but rather the lack of application-specific assumptions on the data passed to the generic algorithms (such as the typical size of a move vector, or the degree of sortedness of moves etc.)
For a 10% slowdown, I think my engine Nebiyu would really benefit from the added productivity. Right now it is a mess handling all those games with special needs every where.
BTW, the new C++11 standard does create some very nice opportunities for optimization. E.g. the new move semantics will eliminate copy-overhead for some common C++ idioms. In Stockfish e.g. one could streamline the insertion of TT entries quite a bit. The new lambda functionality can likewise remove some of the function objects / passed function pointers.
Yes C++11 looks interesting. It seems it has incorporated lots of features that C#/Java do already have except maybe garbage collection. Lambda expressions, regular expressions , threading library and most of boost sure will make life easier for many projects (maybe even for chess). Adding a GC will take away too much from the fact that c/c++ is meant for speed. But clearly c++ was falling behind those two as a modern programming language and this new version may just reinvigorate it. In general the bigger the library the better for me...others may disagree though. In a c++ project where I had to collect memory back from heap allocated objects as soon as they go out of scope, I ended up using lots of braces for no other reason than to force a destructor call. Should have used a language with a GC there...
OTOH, programmer productivity goes up greatly because you can use higher-level (and most often higher-quality!) code. This saves enormously on debugging common vector & list routines such as searching, sorting and partioning. Algorithmic improvements will usually catch up quickly with raw speedup improvements. The Stockfish team emphasizes raw performance, but still produces cleaner code than anything else that is out there. Stockfish also does not depend on high-level libraries such as Boost (the entire logging facility could have been largely imported). It's a reasonable trade-off now, but in the long run I think it's a burden for maintenance.
Exactly stockfish don't use fancy c++ stuff where it matters like the rest of us. So for it to be representative c++ chess engine it should use it in search , eval, and move generation (hearts of a chess engine). For example author of Blitz++ didn't complain about the difficulty of adding matrix A + B efficiently in c++ with all the copies that compiler may generate, they just came up with a solution to get equal performance as a simple for loop of fortran would achieve. Now that is what I call art and it will motivate others to do numerical computation with the language.
Template just lets you detect the most common macro errors at compile-time, rather than at run-time. 
