In my experience, once you stop trying to record clicks, often on elements that will dynamically change outside of your control, and instead use proper coded tests for locating UI elements like Selenium 2+ gives you, it's much easier to have both tests that don't break and tests that are easy to maintain.
In my experience, record and playback can work well. Especially visual, screenshot-based solutions like Sikuli or Kantu are actually more stable then most developers think. And the beauty of them is that they can also be used by non-developers, i. e. "manual testers", so the developers can actually work on the main product, not the test suite.
As a counter to your experience I've spent a great amount of time stamping out issues with record-and-playback tests. They're a passable stop-gap if you desperately need testing and, for whatever reason, haven't written any. Sikuli is possibly worse, though it's been a few years since we last evaluated it and quickly decided against using it in any serious capacity.
Using manual testers as discount automation testers is a waste of everyone's time. They're the true experts in actual use of the product. I've seen them find more issues that from a code perspective shouldn't really be possible that it's given me an implicit trust and respect of their abilities. If someone wants automated testing it's another thing they're going to have to spend money on. Doing it half-assed is more than likely going to do more harm than good.
Kinda led me to create https://sourceforge.net/projects/sikuli4net/
Sikuli4net is pretty much a dead project now due to me having absolutely no time to devote to it though. :(
But the focus of the academic journal (not the blog) was more of a focus on general record/playback testing tools, not just Selenium IDE.
The biggest reason for this is because they don't have the time or knowledge to re-write their scripts to use WebDriver.
So even though Selenium has dropped support for IDE a long time ago, it's still being used by testers.