I suspect you are talking about the case when the arguments for the constructor are known in advance before deployment. In this case you are right it's more efficient to get rid of the constructor parameters and add them as constants in the code thus potentially eliminating a few state variables and saving on gas.
There are cases, however, when it's not possible to replace state variables with constants in this way, e.g. if a state variable must be mutable i.e. it can be updated later in the lifecycle of the contract. So eliminating the constructor parameters will not be of much benefit in this case.
Another case when constructor parameters are useful is when contract instances are created inside another contract. Let's say there is contract A, that needs to create instances of contract B and these instances should have different names. Name in this case has to be a constructor parameter. You could instead update the bytecode of B with the new name every time before deploying it (this is possible as @flygoing mentioned in the comments) but this will require use of assembly and be potentially error-prone.
Hope my explanations are clear.