Therefore it can't be the whole point, because that mechanism already exists, which most commenters here seem to have not realised.
The actual point is, that it gives you more powerful exceptions, but you don't actually need them.
Example: main calls calculateSth calls f1 calls f2 calls f3 calls readFiles
If we want to decide in main how we want to react to errors when reading files, we need to pass the function to handle errors thorught the whole chain.
With conditions calculateSth,f1,f2 and f3 don't need to know about our condition.
This also means that when you add new condition to function that you invoke in many places, you need much less changes everywhere.
Yes, from what I understand about Conditions (IANACL), they can be implemented with first class functions and dynamic variables. And dynamic variables can be implemented by passing an extra argument to every function. And function arguments can be implemented with well-named global variables. And functions can be implemented with computed gotos and a reified global stack variable.
But the point of a language is to create a common vocabulary with which programmers can think and talk to machines and each other. Try to reduce everything to a simpler form and everyone ends up reimplementing the higher level concepts in incomplete or at least incompatible ways with everyone else. There is a need for experimentation and turnover to figure out which higher level constructs are best, but this is entering the realm of language design and should not be a required part of application programming.
I feel the most important thing is conventions, and having a weaker model of exceptions as a convention, affects all/most code in the platform. In Java most libraries throw exceptions and so you will probably use exceptions. In C most libraries return an int return value for error/success and you'll probably use that. In Common Lisp, people use conditions.
So, what I'm trying to say, is that when considering this kind of design decisions in a language, we have to take into account how it affects the whole platform (and not just see if it is possible to implement it any other way in our particular language of choice). The same reasoning should be applied for object orientated features, scoping rules, calling conventions, multiple-value returns, lazy evaluation, macros, continuations, modules, type systems, naming conventions, etc.
