I’d use it only as an optimization (or code simplification) when I would otherwise have put a try-catch block immediately around a use of regular new, catching std::bad_alloc.
This is quite a rare situation, because it’s rare to be able to usefully handle out-of-memory right there at the call site. Usually you allocate memory because you need it, not because you’d quite like to have it but can live without. Code that passes null pointers back up a chain of callers until eventually someone can deal with the problem isn’t idiomatic C++.
It can happen though that the error genuinely can be handled immediately. For example you might be in a situation where you’ll use one algorithm or technique given sufficient working space, and a different, slower algorithm or technique without. Then again, would you be allocating such working space directly with new? Not normally. And anyway, you sometimes have to be careful with that approach, because if your OS overcommits then in general you cannot handle out of memory gracefully at the application level.
Note that an expression involving std::nothrow can still throw an exception (in particular from any constructor of the object being allocated), so it’s only one thing needed if you’re hoping to avoid throwing an exception. You also have to ensure that the constructor won’t throw.
As far as I’m concerned the days of C++ programs that don’t use exceptions at all, are over. I suppose if they resumed for me, due to some particular style guide, then that’s the other likely reason for needing nothrow new.