Perhaps he's saying relying on the break condition that's inside the loop.

It's not - it just feel more dangerous somehow.

The use cases definitely do come up where you want the logic inside the loop to execute at least once. One common use case I have is validating user input in console applications. Put the instructions for validating the user's inputs inside a do while and then run logic to validate it at the end - that way you can easily loop back to the start and re-prompt them for the user input again.

IMO I find it really useful in scenarios where you have a set condition that needs to be met (and can always be met so it's not endless) and looping through to achieve it. I wrote a simple part calculation for a production company I worked for. Essentially while parts_needed < parts packed, pack qty 'x' of part 1, and qty 'x' of part 2 until all parts were filled to the correct amounts. Though it can be done with either / both I just find it more legible.

I got an application that runs through a big calculation that has to pass several sanity checks along the way. If any check fails, the input parameters are tweaked and the calculation starts again from the top, iteratively approaching the ideal solution. Do-while is perfect for this.

It beats recursion in non-tail-call-optimized implementations (JavaScript...). And while this could be done just as well with a comon while loop plus a flag variable, I like the way the syntax of do-while naturally reads as, "Do [thing]. ... Did it work? No? Do it again".

I'd still argue it's redundant. If they got rid of it tomorrow I'd refactor and cope with no complaints. But as long as it's around, I like using it.