Think of exceptions like error codes. Most often one just checks if there is an error or not. Sometimes, one checks for specific error codes in addition to the general check. It would be rare to check every single error code, though possible.
By this analogy, I think the recommendation to check each type of exception is very uncommon.
Most importantly, make sure you do always catch exceptions at some level and handle them somehow (even if it's just logging), and also make sure no exception/error information is lost (e.g. blank catch block, not logging all exception details, not re-throwing with an inner exception so the original stack is lost, etc.).
1. Exception handling is a form of flow control
Once you understand exceptions are a normal part of program flow, you begin to see how they fit into the broader logic. They help encapsulate and guide handling of common error cases.
2. There's no need to be over-granular
It's not necessary to go overboard and capture every single possible exception. You can explicitly capture the most common exceptions, log them, and handle/cleanup appropriately. Then you can have a fallback global trap to log and catch any others. If you start to see something unexpected a lot, then you can add an explicit handler for it if needed. It's mostly just about having specific cleanup and good logging for awareness of runtime issues.
Also, when handling each type of exception, that often means we need to import those specific exceptions. Importing tens of exceptions at the top of the file is just not an elegant approach imo. Also, we can never be sure that we've found all types of exceptions.