I mean, you wouldn't want an uninitialised instance of your class floating around in the wild would you?

I aim for avoiding initialization most of the time. :) I/O heavy initialization for database backed objects is best saved until absolutely needed, and possibly saved until more than one object can be initialized at the same time. How many objects get constructed and never used? Make construction cheap and it doesn't matter. Save the memory and disk and CPU for the stuff you really need to use.

I have a rule now for my code...save all work until it's proven to be necessary. Don't initialize an object until a method is called on that object that requires it to be initialized. Extending that, use require-on-demand instead of 'use'. Don't even compile dependency modules until a caller wants an object of their type constructed. autouse packages when trying to get legacy code to perform (just refactor out those pesky imports and that indirect object syntax ... your maintainers don't really want either of those anyway). Use Abstract Factory with a require-on-demand design for new code. Design for modular run-time, not just modular maintain-time.

As long as objects can identify themselves uniquely and know whether they've been initialized or not, then the rest is no big deal. No need for fully initialized objects at all times.