You will become a master developer when you can explain why the thing never should have been made in the first place and then lead an effort to tear it out and throw it away.
You become a guru developer when you realise that judging any code based on any metric without knowing the full context is often misleading. Yes, in general removing code is good, but does that mean removing the full project and committing that is the best change you can do?
Imagine you're developing a storage with S3-compatible API that is meant for public consumption, but you don't actually have something to store. Then yeah, bad idea to write some sort of storage system.
Point being, yes, of course you can come up with 1000s of examples where it's good/bad to delete all code. The point of my comment wasn't "It's never good to remove all code for a project" but rather "If this change is good or not depends on variables from outside the Git repository".
The problem is that this is always, always harder to sell than a new feature/launch/whatever addition. You might be a master developer but you'll not be the highest paid / highest level.
The best commits have more red than green.