That takes time and effort, something which is often in short supply. Easier to just slap any old captcha on there, even a mostly ineffective one will stop the drive-by scripts.
I had to implement a non-CAPTCHA method of stopping spammer signups to our forums, and after a day of work I had something that still let through 2-3 spammers a day. A CAPTCHA would have taken under an hour (plugins available) and probably have stopped more.
/s
If you can come up with something else that can distinguish legitimate users and bad guys, you'd be a very popular guy.
Oftentimes, a simple JavaScript-based spam protection is enough.
Pure evil!
Literally hyperbole.
If you have a decent site, you can afford to review/delete/block spam afterwards, but if you have a small site and don't babysit it every dey, then a tough captcha is an absolute requirement.
I run a phpBB forum and 2 blogs. They got the standard spam like everyone else. Once I installed Spam Destroyer for Wordpress and made a 3-line JS-based modification for phpBB, I reduced spam by approximately 99,99%.
My main Web App gets something like 40,000 visits per week and is online since 2006. I never bothered with a CAPTCHA and there are hardly any spam signups. Same JS-based spam protection mechanism.
For years, I had a non-captcha on my blog that simply read:
Enter the word "elbow": ________
Enter the word "humour", but with American spelling: ________
This started to break down eventually as well. My latest effort, done more for fun than effectiveness, is to implement a hashcash proof-of-work system in Javascript. In short, the server sends a random salt to the client, and the client must then come up with a string which, when concatenated with the salt, has an SHA-1 hash with a certain number of leading zero bits. This is easy to verify (the server just takes the client's result, performs a hash, counts the leading zero bits) but hard to produce (the client has to brute-force it).
The relative slowness of JavaScript crypto makes this not actually very useful in a theoretical sense. I've calibrated the difficulty to take about 20 seconds of work in the browser, but a decent native code implementation can do the same amount of work in maybe a tenth of a second. So, against a determined attacker, it won't be much of an obstacle.
But as a relatively small site with a completely custom anti-spam solution, I don't get determined attackers. I get the occasional spam message with this in place, but from the server logs it's obvious that it's actual real human beings firing up the comment form and waiting the ~20 seconds for the hashcash to complete before posting their comment. Terribly inefficient for them, and it keeps stuff down to a manageable level.
In summary, if you have a small site, you can throw up nearly any custom anti-spam measure, no matter how silly or easy, and have it be effective. A standard captcha may be easier to add than a non-standard anything, but it's definitely not an "absolute requirement". Big sites are completely different, since they'll attract enough spammer attention for site-specific attacks.
It totally wasn't the most pleasant experience.
Sure, the computer does not get it 100% of the time, but it gets it more often then me, and fails faster.
It wasn't until the social virus was released on 4chan that uploaded itself, along with any random file it happens to find in Documents or other sensitive areas publicly, that the captchas were put in place.
This evolved to the point where they started selling 4chan as a service without a captcha (I'm actually all for that).
Sometimes there is just no way around the problem.