4 of 5 edited title

What do OOP languages gain from having constructors that always return an object?

In what seems like a deliberate design decision, C++ does not have a null value for objects and references. This makes using objects and references very elegant since we don't have to perform null checks. It also means constructors must always return an object:

void main () {
    // o is guaranteed to be non-null by c++:
    Object o = new Object();         

// Allowing this hypothetical "failing" constructor would break the guarantee:
Object() { return void }

Sometimes object creation has to fail, an easy example being a Connection object. Since C++ does not allow this, programmers have developed alternatives: initialization methods (with various names), static builder methods, "Factories" that do not use any polymorphism, and null objects. One reason for adding exceptions may have been as a way to go around this limitation of C++ constructors, but either way, it is a tradeoff - we avoid null checks but sometimes have awkward construction.

But all of this falls apart when we consider newer OOP languages like Java and C#. There, references are allowed to be null, yet constructors work like C++ and must not fail. So we get to write both null checks and alternative construction schemes (having to write factories, init methods etc). What benefits does this bring?