It's less subjective than that. I find exceptions to sort-of work in "boring" software (short running programs like scripts, or systems comprised of short running processes), or in software with low quality standards (sorry to be blunt).
It's nice that I can bang out a 100 line Python batch script, and catch and transform that one exception, and otherwise just be happy when the script quits automatically because a file could not be created or some input data was malformed. Whatever, I'll "rm -rf" my temp directory and re-try.
Exceptions are also popular in enterprise software - all issues with real-world business logic aside, my idea is that enterprise software doesn't have a lot of complex state after all. There is a domain model that is pretty much single-state as far as most operations on it are concerned. Normally errors are not expected to happen, and for some exceptional situations programmers simply don't care about writing error handling code - the GC will probably clean up to a reasonable state to serve the next request, it will do so in reasonable time, and all will probably just work, and nobody needs to understand what went wrong. (Maybe someone will later have a manual look at the stack trace from when the exception was thrown).
If you're not a "happy path" programmer and need control over what situations are handled and when, I don't see that there is a good way with exceptions - because exceptions take away control (control flow) and take away detailed error information as gingerBill described. In my perception (while I don't read a lot of code and certainly not a lot of GC'ed code) most code never cares to catch exceptions, because it's inconvenient, and because that was the idea behind exceptions.
Hope I made a reasonable argument. Can't see anything subjective about it.