I say it’s a bad idea, generally (with some exceptions, perhaps).
First, your database should be backed up regularly, so you should never be in a situation where you would lose data permanently because of a DELETE (unless it’s a deletion of just-added data, of course).
Second, a soft delete like this means you now have to include a WHERE IsDeleted = false clause in every query on this table (and so much worse if you’re JOINing these tables). A mistake here would be caught as soon as a user or tester noticed a deleted record showing up again, which might take some time. Also, it would be easy for a developer to omit the WHERE clause from COUNT(*) queries, which might take even longer to discover (I worked on one project where this had been happening for years; not many records were ever “deleted”, so the totals were close to what was expected and no one noticed).
Finally, a soft delete will work on a table with artificial keys, but potentially won’t work on a table with a natural primary key (e.g. you “delete” someone from a table keyed by Social Security Number – what do you do when you need to add him back? Please don’t say “include IsDeleted in a compound primary key”.).
In a design review, I would expect the developer to demonstrate an awareness of the costs and benefits and to present an excellent reason for doing soft deletes in this manner. “Why not do it?” is not an excellent reason.