Is there any situation in industrial object-oriented programming when the dependency inversion principle should not be used?
Yes: whenever supporting the easy exchange of collaborators would be more work than it saves, then it isn't worthwhile.
In general, there are very few principles that you should follow in 100% of cases. Decoupling is generally good because it allows reuse, better understanding of large code bases, faster implementation of unexpected changes, etc. It looks especially good in comparison with current industry practice in the 70s and 80s, when monolithic one-module applications and absolute, pervasive dependence on one database or lookup provider was commonplace. (Back then, modularization wasn't a thing, and many programming languages didn't support it, often you didn't even have a choice of database, etc.) This created problems when systems became really big, and on the whole, modern software architecture principles turned out to work better than the old way of doing things. To a good approximation, more decoupling (which DI is primarily used for) is good.
But there is always a point of diminishing returns. Any given system has to be put out in a certain time frame and at a limited cost or it isn't worthwhile. Some systems aren't so big that you need to separate everything from everything else to understand them. Sometimes the risk that a collaborator will change isn't big enough to justify the extra architecting necessary to make it easily replaceable. (New messaging protocols pop up every month, but next year's new big thing will probably still run over TCP/IP). Deciding whether you need to be able to react nimbly to a potential future change comes down to a risk-management decision like any other in engineering.