The caller knows what to do because it has requirements it wants to fulfill. If you want a parser that silently ignores the errors you write an exception handler that invokes the ’skip-line’ restart. If you want to log you do that etc..

This problem is certainly solvable in other ways - you could implement an error callback, or maybe an abstract base class or strategy pattern or something. AFAICS the benefit of the condition system is that it’s quick and easy to do the right thing upfront - you defer the error conditions to the caller, who is more likely to know what it wants to do and can change later.

E.g. If I’m writing a parse function in python/java I don’t think ‘this should be an abstract base class because I might want to reuse it in other circumstances later’ - I just write and test the function (simplest thing).
Then when the program wants to ignore unparseable lines I might add a flag-argument to the function. Finally I might refactor it into a class structure later when I need to use it in other systems.
With conditions I just add the resume points to the function - the refactoring is small and idiomatic.

(btw, it’s early days for me and common lisp, so I don’t have any practical experience of how well this works)