I don't care how good the internal assertions are. Throwing a bunch of random load at a particular module, and verifying that none of the assertions fired, is not a unit test. It's a stress test, and it's sometimes a good idea, but it serves a different purpose.
A unit test is a contract for the code under test. It says "given input X, you must do Y." If you write a contract that says "given input X, don't assert out" then in the long run all you will get is code that doesn't assert.
A unit test demonstrates that you understand what the requirements of the module are, and what the corner cases are. If you discover a previously unknown or untested corner case (i.e., a bug), then adding a unit test documents what the proper behavior is. If you can't figure out what the proper behavior is, or what set of circumstances led to the bug, you haven't finished fixing the bug.
A unit test should show specific examples that humans can verify and learn from. An assertion is very implementation-dependent. A future developer might refactor, decide that the assertion is now irrelevant, and reintroduce the bug it was meant to catch. A unit test that verifies output provides a record of the cases that are important, and a set of examples of correct functioning that both current and future reviewers can comprehend.