No. It's not wrong.
The priority should be for the contract to protect the integrity of the application state at all times. An invalid configuration must not be allowed to persist even if it's the result of a developer/operations/deployment error.
Allowing the contract to carry on as if nothing is wrong when actually something is very wrong is incorrect, in my opinion. I'm thinking of a particular incident that resulted in the loss of upwards of USD $100 million. As with most catastrophies, there are multiple factors to consider. One can think of various safety measures, any one of which would have prevented the unfortunate sequence of events.
Constructor arguments are not the only method of ensuring a completely valid configuration before normal processing begins. One can consider a process with multiple calls to multiple contracts to rig up inter-dependencies. That would be okay as well, provided the "normal" functions are guarded with something like
Nothing at all wrong with a constructor that refuses to proceed unless the configuration is value. This is often the simplest method and easiest to reason about, as it should be. Don't let the possible loss of a little gas, once, cause any concern at all.
Hope it helps.