I agree that in Jack's specific examples you don't need the constructor: the constructor trivially saves the parameters into instance variables. However, one thing that hasn't been mention is when the setup of the class is non-trivial, which most likely requires breaking it down its helper methods that's only specific to that class. Exposing those helper methods outside of the class can potentially add as much unnecessary complexity to the code base (i.e. is this a helper method for another method or if this is standalone method, how does this fit into what I'm trying to achieve?). Yes, this could be mitigated with good documentation, but classes exist for this specific reason.

Decoupling. For example if your code requires access to an outside resource (database, message queue, email service) you can mock said resource in order to test the code in isolation.