the counter point:

TDD seems badly suited to *really* rapid prototyping.

I often use TDD for production code that I need to work long after i
have moved on,
or for production apps that many people need to work on. but its kind
of like red-tape.
if you dont trust yourself or others, then get a contract. if you do,
then word of mouth is fine.

also its an issue of scale - if you are working on sth for > 1 week,
you need tests to keep it all together.
but many proofs are done over a weekend or a hectic all-nighter.

if you are looking for a proof of concept - if something works or not
(today, and you don't care about tomorrow) then writing iron-clad
tests for everything seems redundant. if you have a level of
confidence, you can fly blind, and i feel get into a much better state
of flow without tests. a week later things may not work as planned
tho.

additionally tests prove things on a very abstract level. if the
wright brothers had spent a bunch of time with RSpec they would have
theoretically proved their model of a cylinder would have enough
horsepower to lift it itself. and the tests would ensure that the next
change to the air system, would be guaranteed to not break the
cylinders. good, solid, mainstream engineering.

but they would never have captured people's imaginations as much as a
working flying machine.
if it blew up in a future flight, at least it flew first...

/dc