IMHO the beauty of "let it crash" is that you can code very tersely while maintaining data safety. In order for "let it crash" to work you need two things:
1. A tech stack that isolates crashes such that they do not affect the rest of the system. Example: you receive a malformed API response. The code responsible for parsing it crashes, but the rest of your application does not.
2. You use this to code in a declarative style.
Coding declaratively means your code has the shape of the data you expect to have.
Example (in elixir):
Let's say you are calling an external API where you expect to get back a list with a single element.
If you code non decleratively, your code might look like this:
thing_i_want = List.first(my_api_response)
Now imagine that for some reason the external API sent you a list with
two elements. That code still runs! It doesn't crash, but you are now in a strange state. The data you are passing into the system is unexpected.
Coding declaratively you would write:
[thing_i_want] = my_api_response
In that case, if for whatever reason the external API sends you a list with more than one element the code will crash. In BEAM languages that is fine--the rest of the application should be ok, and you should log why you crashed and when, so you can look into it, but you are not ingesting bad data into the system.
The alternative is to code defensively: check the lenght of the list before extracting the first/only element. That works, but it tends to be very verbose and more importantly it means the entire call stack needs to be aware that you might get exceptions bubbled up from anywhwere.
Of course, for this to work you need software that has lightweight processes and a supervisor architecture..not usually worth it unless you're getting it for free! (as with elixir/erlang).