Audio captchas are considered broken completely (search for various papers over the past decade, including one from CMU), so it has limited usefulness only in a very narrow context in practice. I suspect this is a harbinger of things to come - as we close the gap on passing the Turing test, captchas are likely to get less effective, and we will need to transition to a very different solution for bot detection.
often it's easier to just use a website as api instead of using some broken xml nightmare that requires knowledge of the database tables.
If the concern is rate limiting then just rate limit the website. And if you don't like people operating websites with bots then I don't know, maybe stop making websites.
Easy proxying means rate limiting doesn’t really help all that much to defeat bots. And then if you do something like blocking or severely restricting something like Tor (the world's largest open proxy and hence, primary abusive traffic source; something which it would make sense to throw extra bot walls in front of), privacy and accessibility advocates jump down your throat.
This is a no-win situation. I’m not convinced it’s possible to have ones cake and eat it too, here. Someone upthread said “security, privacy, accessibility, pick any two”, and I have yet to see any evidence of a third option.
I think you do not understand why website owners use captcha. Website owners use captcha services, because doing so saves money for them.
Captcha will stop saving money, if the captcha becomes so ineffective that the short-term and the long-term downside (annoying users who are subjected to captcha) exceeds the cost saving ("cost" here is potentially many different things - it could be quality of service for normal users, it could be opportunity cost, it could be the cost of serving the traffic like network bandwidth or cpu or database capacity).
