It seems to me that most discussions about exceptions are missing the point.

Most people reiterate "exceptions should be used only for exceptional circumstances" and then argue about what does or does not qualify as "exceptional circumstances".

That is a meaningless semantic game. Instead, I propose that the use of exceptions should be based on their nature as language features. Exceptions have three core properties:

1. They can transfer control flow up the call stack without requiring any changes in the code in between.
2. They cannot be ignored silently. If there is no code handling them, your application will crash with a nice stack trace telling you what happened. And code that catches and ignores them is at least a very visible red flag.
3. They syntactically represent alternative results of a method, and you can have an arbitrary number of different ones.

And therefore exceptions should be used when these properties provide a benefit:

1. When you want to give the caller freedom to decide the granularity of error handling - i.e. if sometimes it would make sense for a caller to immediately do something specific, but in other circumstances it could be handled by a generic error handler (e.g. one that returns a HTTP 500 response).
2. When there is a case that callers are likely to ignore and you don't want them to.
3. When your method has a natural return value, but also special cases where the return value doesn't exist.

Especially points 2 and 3 are a good match for the "exceptional circumstances" definition, which is probably where exceptions got their name, but these more specific properties allow for a more concrete reasoning why exceptions should or should not be used in a concrete case.

And to finally answe the question as stated: No, exceptions are useful in many cases where you do not want the program to crash.

It seems to me that most discussions about exceptions are missing the point.

Most people reiterate "exceptions should be used only for exceptional circumstances" and then argue about their differing opinions of what does or does not qualify as "exceptional circumstances".

That is a meaningless semantic game. Instead, I propose that the use of exceptions should be based on their nature as language features. Exceptions have three core properties:

1. They can transfer control flow up the call stack without requiring any changes in the code in between.
2. They cannot be ignored silently. If there is no code handling them, your application will crash with a nice stack trace telling you what happened. And code that catches and ignores them is at least a very visible red flag.
3. They syntactically represent alternative results of a method, you can have an arbitrary number of different ones, and catch clauses allow you to handle them selectively.

And therefore exceptions should be used when these properties provide a benefit:

1. When you want to give the caller freedom to decide the granularity of error handling - i.e. if sometimes it would make sense for a caller to immediately do something specific, but in other circumstances it could be handled by a generic error handler (e.g. one that returns a HTTP 500 response).
2. When there is a case that callers are likely to ignore and you don't want them to.
3. When your method has a natural return value, but also special cases where the return value doesn't exist, and they might need to be handled in different places.

Especially points 2 and 3 are a good match for the "exceptional circumstances" definition, which is probably where exceptions got their name, but these more specific properties allow for a more concrete reasoning why exceptions should or should not be used in a concrete case.

And to finally answe the question as stated: No, exceptions are useful in many cases where you do not want the program to crash.