Yes but with a lot of care!

Let me clarify that.

You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to make your home more habitable. Its a feeling, and you will know it.

That being said, you are working in a complicated symathesis. Anything you do do is likely to go wrong, and probably will make things worse at least in the short term, because a simple change has ripples. So first off become humble, I don't mean become a push over or accept that things must be bad, I mean come to terms with the fact that your good intentions are going to turn on you viciously.

The Problem

With the best of intentions you might feel that a broad sweeping change needs to happen, and I don't disagree that these situations do exist, but take a moment to think about it. The current system is working, you and your team are producing code, perhaps its slow, perhaps its painful, but it is working and all of you have experience on how to do this. You know roughly what to expect, in short you are practiced professionals in this system.

After the sweeping change though no one, except perhaps the implementer, knows what to expect. In short everyone has been reset to a neophyte level in this part of the system. That's not good. Neophytes have to learn the new rules which takes time. In that time neophytes are making mistakes because they aren't practiced. Those mistakes become part of the system, which you now have to live with and its no where near as sparkly now.

A Way Forward

There are times when slash, burn, and rebuild is by far the best you can do. Its particularly attractive if no one is practiced in the old system, because the only thing being lost is the codified knowledge. If this knowledge is thoroughly incomprehensible then its already lost, and starting over is the only choice. Conversely if the method of codification, or how it used is problematic but functioning, that knowledge is still accessible, and perhaps its worth keeping, perhaps its not - Just don't take the decision lightly.

The other choice is to work with the system so that everyone has a frame of reference, but to change small parts of the system so that everyone on the team is aware, or if they are not aware of the change, it is both easy to notice and easy to learn. This is the basis for the practices called Kaizen. A more developer orientated formula is presented in the presentation Shaving the Golden Yak, I highly recommend watching it and thinking it through.

So find a small thing that can be changed that will improve your life, and hopefully those of a few others. Fix or improve the situation. This will give you practice and experience on putting changes into practice. Make sure you get feedback: could you have discussed it better, was it actually useful, did it upset another part of the system. Develop your feel for what can be done and how to do it.

Now three things have happened:

you have improved the system,

you have obtained experience on how to change the system

the team has seen you successfully change the system.

Now pick another thing to improve, as your experience grows and as you eliminate low hanging problems you will start to confront the harder issues in the system but at least now when you say we have to change X: