I would say this is not good practice. As you pointed out, this would confuse the roles of Assertions and Exceptions. The topic is somewhat common, this link has a lot of nice ideas. By combining exceptions and assertions, you end up with a conundrum... is the class an exception helper, or is it an assertion helper?
Since assertions are compiled out of the Release build, would your assertion class even work in Release mode? It would be non-conventional to expect an Assertion class to work in release mode. So, would your Assertion class throw the exceptions in Release mode? There lies the confusion. By convention, I would say the exception should not be thrown when using an Assert Class (in Release mode) because it is understood that assertions are not part of a Release build.
The code above should not make 'Exception Handling' easier nor harder, it should be the same since the exception handling depends on what is catching the exception in the stack. I think you are really asking if it makes throwing Exceptions easier or harder. I think it could make dealing with your exceptions easier. I also think it is probably unnecessary. What is most important is that you are consistent with this... if you are going to use an ExceptionHelper class, then embrace it and be consistent... otherwise it is all done for naught.
Debug.Assert:
- Use liberally
- Use whenever there is a chance that an assumption could be wrong
- Used to help other programmers, not necessarily the end user
- Should never affect the flow of the program
- Not compiled in Release builds
- Always yells 'BLOODY MURDER' when something unexpected happens, this is a good thing
- many other reasons, I'm not aiming for a complete list
Exceptions:
- Can be caused for any reason, it is not always known why
- Always in debug or release builds
- Pertains to how the application flows
- Some exception handlers may silently swallow an exception and you would never know it
- many other reasons, I'm not aiming for a complete list