It's not a conservative guess. It's objectively wrong. Inner join means "include only matching records," and if nulls are being dropped, it's because the developer doesn't know that in SQL, null != null, and they need to address the defect in the code that excludes that case.

If you're debugging something, there tends to be a defect to address in the vicinity ;-) Maybe also add there is a difference between an ad hock query, where conservative guesses are acceptable, and queries built into code, where you'd better know what you're doing.

I've done it a few times, typically in a situation where some random contractor dropped a minimal effort database design right into production. No constraints like not null of course, that would mean the application shows an error and contractor can't have that because it would imply they did something bad.

So the DB chugs along for months, accreting damaged data. Then something finally crashes bad enough to wake up the management, which instantly switches from 'everything is perfect lalalalaaa' messages into blind panic mode.

So you get thrown into the mess, sometimes without even knowing what the application is supposed to do, with the directive: Fix this, we're bleeding money. After looking around for about 5 seconds, it turns out everything is objectively wrong. You can't fix all fires at the same time, you have to put out one at a time, and try not to make it accidentally worse. That's when you use left joins as a conservative guess, at least until you've built up enough knowledge.