''I've played Chess.  Speed is Queen.''

Some programmers are of the firm and entrenched belief that SpeedIsKing, referring to the speed at which the final program runs rather than the speed at which they were able to produce it.  These people will use speed-hacks in CeeLanguage, utilize Assembler if it could gain them a few CPU cycles, etc. and will generally shun languages that use ManagedCode, required DynamicTyping, anything interpreted, and anything that they believe utilizes an excessive number of internal pointers (e.g. Lisp).

These people generally cause themselves more headaches struggling with correctness than they gain in speed.

However, there is something to be said for speed.  Forcing the CPU to crank more efficiently and more effectively than the next program... well... leaves more time for the next program.  CPU-intensive tasks like decoding movies or calculating the next move in a timed Chess tourney can gain much advantage by being a little bit faster.

Languages that largely forsake speed, planting that task solely on the implementation and/or compiler and providing few provisions for optimization, are inappropriate for many sorts of programming.  These languages are generally chosen for their flexibility or their intrinsic 'beauty' -- syntactic clarity generally provided, in part, by a reduced amount of text.  

If any language is to support both locations -- systems programming AND flexible scripting -- it must make beauty, flexibility, and correctness several of its components... but it cannot sacrifice speed to gain them.