Like many questions in software development, the answer again is "it depends".
Some of the articles other questions linked in answers to this advocate for 'lightweight' constructors that avoid doing any 'real work'. However, there are many circumstances where it is appropriate to initialize and begin doing work in the constructor.
Usually, it's appropriate when instantiation is cheap, when instantiating has essentially one conceptual successful outcome, and where there is nothing valid or meaningful to do between construction and a hypothetical start.
To start, let's characterize the idea of a Start() method is. In many situations it would instead be called Init() or Open() or similar. It would likely encompass stuff like opening or creating files, opening network ports or connections, connecting to a database, accessing hardware, starting new threads, etc. What are some situations where it would make sense to create an object and start performing those operations right away?
Take the example of something that deals with files on the file system. If we take the position that we should do minimal work in the constructor, then a typical usage is we instantiate our filewriter class, then later call Open() or similar, then later start providing data in some way. Since we want our object to be in a valid state at all times, we should verify we can access the file upon instantiation. If the file can't be accessed, we have to throw an exception upon construction. If everything is good to go, we can later call Open() and get to work. But wait, life is never that simple. We've created a race condition, as it's possible that between instantiation and Open(), the file has become inaccessible. So, we'd need to encase Open() in another try/catch to handle that scenario. How is that better that instantiating and opening in one operation? I'd argue that in this scenario the additional method is worse than doing the work in the constructor.
Even more complex instantiation procedures can be performed with paradigm in an easy to debug and test way, and dependency injection is often the means to do that. A database interface being provided an instantiated DatabaseConnection is a common example you may have seen in the wild. Instantiated, valid objects are progressively injected into objects using them, guaranteeing a valid state along the way.
Some comments and answers have stated that sometimes, you want to instantiate your object and later have it start doing its work, which to me makes little sense for cheap objects. It's pretty commonly stated to declare your variables as close to as when you're going to use them, why would that rule be different with objects? And if you do have them separate, what value are you providing yourself by keeping them separate? If you are opening a network port, at the moment you're ready, you have all the information you need to do so, so what real difference is there between a class that makes you call an additional method?
By doing the Start() work in the constructor, you are able to ensure that there is a single way to use a class, for that single way to be the right way, and for the compiler to enforce it for you. Having separate start methods, you have temporal coupling that trades off compile time programming errors for runtime errors. In a way, starting up in the constructor let's you reap some of the conceptual benefits of immutable objects, but for objects that do things.
Now, like I said, sometimes the answer is yes, sometimes it's no. Sometimes it does make sense to have an exposed Start() method. Sometimes you're interfacing with some other system where the RAII and OOP and similar paradigms don't exist, and there aren't exceptions, etc, and you have no choice. Sometimes instantiating is really expensive. In those cases and others it makes sense to have separate start methods. Only you can decide what's appropriate.
