In classical OOP, the notion of encapsulation embodies the idea of combining data with code; that is, providing methods that act specifically on the data they represent. So, for example, a Customer object contains only those methods which pertain specifically to customer "behavior."
Persisting objects is an orthogonal concern.
The Customer object should not know anything about how it is being saved or retrieved from a database, XML file, or whatever (the concept is called Persistence Ignorance). This is why the preferred approach, especially in a large system, is to utilize some generalized persistence mechanism like an Object Relational Mapper to store and retrieve objects, and then to draw that functionality out through Repository methods that return objects or perform some business action on the data.
This relieves you of the responsibility of having to code a persistence implementation for each and every class you create.
Further Reading
The Unit Of Work Pattern And Persistence Ignorance
I'll give the author the benefit of the doubt and perhaps that is the way things are for Typescript, but otherwise in other environments that's a totally unsubstantiated claim that shouldn't be taken seriously.
Off the top of my head, I can think of a variety of situations where passing data via constructor is good, some that are neutral, but none where it's bad.
If a particular class depends on a particular piece of data in order to be in a valid state and run properly, it makes perfect sense to demand that data in the constructor. A class representing a serial port could take the port name, a file object could require the filename, a drawing canvas requiring its resolution, etc. Unless you pass the data in the constructor, it's possible you could have the object in an invalid state that has to be watched for and checked. Otherwise you can check only at object instantiation and afterwards assume its working for the most part. The authors claim makes that beneficial situation impossible.
Additionally, deciding to forbid passing data in a constructor also makes virtually all immutable objects impossible. Immutable objects have a variety of benefits in many situations, and all of those would be thrown out with the author's policy.
Even if mutable objects are what you want, how is this bad practice:
var blah = new Rectangle(x,y,width,height);
in favor of:
var blah = new Rectangle();
blah.X = x;
blah.Y = y;
blah.Width = width;
blah.Height = height;
Does the author really think the first is bad practice and I should always go with option 2? I think that's crazy talk.
So, since I don't have the book, and wouldn't read it anyway even if I did, I'd view that statement and pretty much any general statement in it at this point with a significant amount of suspicion.
Best Answer
Optional parameters is not a bad practice, definitely not, but sometimes the optional parameters may be optional solely because of what the class does.
You arrived at a problem which is a result of a bad design. You are trying to figure out how to ignore certain properties of a model if you don't use them. The problem is, you are mixing responsibilities of classes together and trying to create a class which knows and does many things. That is pretty bad and might cause you troubles later on, because it will be very difficult to reuse the class in a different environment, for example.
Obviously, when you have a class which can do many operations, there will be a situation where one operation will not need everything that the class contains, but is required for other operations.
What you should be after is splitting your current class into several smaller classes, each being responsible for only one thing and make the class do the thing well. You could have a UserModel, which could be an actual representation of a user in your code, you could then have some sort of service, which would accept the user and do an operation on it. Obviously, if the operation required database access, you would need to provide a class acting as the database accessor to the service class as a dependency as well.
I personally would opt for refactoring the monolithic class into several smaller ones, each taking only the dependency (or dependencies) which it really needs.