Record/Playback also will fail if you have a dynamic application where depending on the data input different things will appear on the screen. Recorders can be handy tools to generate some statements to use in your code, but it definately isn't the final prodct of having a script that you can reuse.
Reliance on record/playback operation results in massively duplicated code and decreased test suite reliability due to the inherent inconsistency of the implementation and because of its unnecessary sensitivity to changes in the AUT. It virtually guarantees high test suite maintenance costs and low overall productivity.
Well structured code can eliminate the duplication, increase reliability, decrease maintenance costs and increase productivity to provide what we all want - a robust and readily extensible solution.
Because in record and play back you would record each of your test cases as an indiviual path though the application under test.
Then what happens when the application changes?
You will have to change or re record all of your scripts that touch on that area again. Since your application changes each time you test it. You won't get much done but record and play back. What happens if the Login changes. That is the primary path throught the whole suite of cases.
The greatest lie that Mercury Sales reps like to perpetrate on the unsuspecting overwhelmed testing manager.
"You don't need to spend much money training or learning how to use the tool. Your testers can just record thier tests and play them back next time."
The best way to gain the most ROI is to modularize your application into actions or activities. Put them in methods tied to a window declaration if possible. Then when the application or an action changes you only have to modify it in one or two places. All of your tests still work at the end of the day. And you didn't have to rerecord them all again.