Imports get treated as a back office problem until the day one fails partway through and half your prices are from last month. Then it becomes everybody's problem.
The good news is that slow imports have a short list of causes, and the first one on that list explains most of them.
Indexing during the import
If indexers are set to update on save, every row in your import triggers reindexing. Import ten thousand products and you have asked the database to rebuild its indexes ten thousand times.
Switching to update by schedule means the import writes the data and the reindex happens once afterwards, in the background. On large catalogues the difference is not a percentage, it is an order of difference in how the evening goes.
Timeouts in the wrong places
A web-based import runs inside a request, and requests have limits: execution time, memory, upload size. Hit any of them and the import stops, usually without a clean rollback.
Anything substantial belongs on the command line, where those limits do not apply in the same way and where you can watch it run. For recurring imports it belongs in an automated job, with logging and an alert when it does not finish.
Doing work you do not need
- Importing all columns when only price and stock changed. A delta import is faster because it is smaller.
- Re-downloading images that have not changed. Image processing is often the slowest part of a product import.
- Running during business hours, so the import and your customers compete for the same database.
When it fails halfway
The important question is not why it failed but what state you are in now. An import that stops partway has applied some rows and not others, and Magento will not tell you which.
That is an argument for two things: run imports in batches small enough to repeat safely, and keep a backup from before the import rather than after. Both are unglamorous and both save an afternoon at some point.