Some people really like the debug feature. My thoughts on it are that it was a pain to get set up and it seemed to be very inconsistent on my systems. When I saw Microsoft removed it, I thought it probably was a feature they didn't want to support going forward.
Since it is removed in SSMS 18, I would not be surprised if support for it is removed in future versions of SQL Server.
I also have some suspicions on it (unconfirmed by me, but guesses about how it works in the back end) in that if the debugger is running, it is going to hold onto locks while it is run, kind of like if you do a BEGIN TRANSACTION without a COMMIT or ROLLBACK. So it could be VERY easy to cause blocking and deadlocks and other headaches. That is another good use case for the PRINT/SELECT as debugging tools - you are less likely to lock the objects for long periods of time. Can still happen, but less likely.
I know when I am debugging code in C# and get interrupted, it is EASY for me to forget I left it running in a paused state and get sucked into a new task for a few hours. This would only impact me though. If I did this on a SQL query I was debugging, I may lock up a test system for hours and would impact other developers.
That being said, I don't think the use of the debugger is a good hill to die on. If he wants to use it, I'd say let him, but I personally would look at other options. I imagine there are other more pressing issues to address than if you should use a version of SSMS that has a debugger built in or not.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!