That makes it really great for popping up some end-to-end "scaffolding" tests during incubation or primary development that you delete or reimplement later with "real" programmatic tests for stabilizing ongoing or incremental development. You don't really want to design the longer-lasting tests until UI flows have gelled, but this sort of quick-and-dirty you can do anytime.
There was also a really intriguing talk a number of GTACs ago that asserted that often the cost of just having to scrap and re-record a replay-based test when it breaks is lower than maintaining an equivalent programmatic one.
I'm not sure I believe that will frequently be true with proper UI automation design (page objects or some other kind of UI map, driving development of test hooks, etc). But I do suspect there's truth there vs. improper UI automation design.
If UI Auto isn't anyone's field on the team or a company doesn't want to sink significant resources into it, it's probably more likely you get the improper than proper designs by scripting, then they turn into maintenance sinkholes over time. At that point maybe record/replay is actually better.