Because, even though there are many C++ unit test systems out there, none covered all the desired properties, although many covered some:

Because it protects the tests from each other. One failed test cannot easily corrupt the environment for any other test.

It also makes it possible to handle inadvertent crashes and even infinite loops as any other failure.

Not really. The overhead is very low, typically much less than a millisecond, so you would need a very long suite of very short tests for this to matter. Experience shows that build-time for a test program is typically much longer than the run-time, and the test programs are usually build-once/run-once.

In addition, crpcut allows you to run tests in parallel, which on a multi-core CPU can reduce run time considerably, especially if individual tests are time consuming.

It is a bad idea just because it is the natural C++ error reporting mechanism. A unit under test could accidentally prevent an error report from being captured. Consider the following class, that needs testing:

    class catchall
    {
    public:
      catchall(int n);
    };

    inline catchall::catchall(int n)
    {
      try {
        stubbed_function(n);
      }
      catch (...)
      {
         std::cerr << "something bad happened, but I saved the day" << std::endl;
      }
    }

Assume a macro THROW_ON_ERROR that behaves like an assert, except that it throws. It is used by the stub to verify that the caller does the right thing.

    int expected_value = 0;
    void stubbed_function(int n)
    {
      THROW_ON_ERROR(n != expected_value);
    }

Now we write a test for this program:

     TEST(construct_catchall_with_wrong_value)
     {
       expected_value = 3;
       catchall object(2);
     }

See what's wrong?

The thought is tempting, but if an early assertion is found to be false, how likely is the result from the rest of the code to be of any real value? In the worst case it will do something harmful. If the test is terminated immediately, it cannot do any further damage.

It was not an easy decision, but the reason is simple. As ugly as the implementation is, the ease of use is phenomenal. You focus on writing test logic instead of writing boiler plate code to match the test engine's implementation.

Most compilers today already support the functionality, so it isn't too outrageous. The advantage gained in ease of writing test cases far outweighs the disadvantage.

	Note
	It is only the test code itself that must be compiled with support for the non-standard functionality. The units under test do not.