The bug causing this crash might be exploitable. Think of a classic buffer overflow: if you overflow a buffer with all zeroes or random data, then the return address most likely gets overwritten with garbage that doesn't point to valid code or a mapped address and the process crashes. But if the attacker specially chose the data they put in the buffer, then they could choose to overwrite the return address with a valid memory address and make the process execute the attacker's own code.

If software written in C/C++ crashes and it's not because of a null pointer dereference specifically, then it's realistic to worry about whether it might be because of an exploitable bug (like a buffer overflow, a double-free, etc). One common way for people to try to find exploitable bugs is to script a program to re-run with random input data to figure out which inputs crash it, and then they debug the crashes to see if they're caused by exploitable bugs.

You're not wrong. AgentME is correct, that crashes can be exploitable, but it is definitely more dangerous for software to continue after its data is corrupted.

The Erlang programming language, in fact, is built around the idea that as soon as you see data you don't expect, you crash, and an external process will start you back up in a known good state.

Depends on what we mean by crash.

If program gives up and exits on receipt of unexpected input, that can be perceived as a "crash" by the user but it's not exploitable.

If it's crashing because execution suddenly jumped somewhere it shouldn't be, and the OS killed it, that's more worriesome.