Yes, he is. I could implement the soft-delete feature in the database, write one class (that sets up the queries chained off of it to be aware of deletions), and then substitute that class for the original via the dependency injection system. Total effort? 15 minutes. Total changes to the application logic and the code that actually queries the database? 0.
If you are writing PHP, where you hard-code a query and then print out HTML as you iterate over the result set, then sure, you're fucked. But not because of soft deletes.
That only works if everyone you work with religiously uses a single ORM and dynamic programming language, because it makes calls to that ORM the only (cumbersome) query language that gives correct results. It doesn't fix the ad hoc SQL query your marketing guys are pasting out of email from a developer who went to another startup last year (yes, I have seen this happen).
So your response basically boils down to "If you do everything else exactly right (and have since the application was designed), this won't bite you"? I'll agree that that's certainly true...
If you are writing PHP, where you hard-code a query and then print out HTML as you iterate over the result set, then sure, you're fucked. But not because of soft deletes.