It's not wrong by itself, but making content encoding implied might become an issue later (e.g. load balancers or CDN, merging content or improving support on east-asian languages). It's likely they've never faced those kind of issues.
Again, it's not implied when you state it categorically in headers. If there's a CDN or load balancer out there which breaks your Content-Type headers it's much, much better to replace it with something which follows HTTP a bit closer.
Very often you don't have control over that. It might be managed by a different team of the organization or might be a poor product purchased by higher management. Or it could be a third party service. You have to code defensively.
Rest assured, I've been in that sort of situation. However I've never found it viable long term to take on additional complexity rather than pushing back against a group which is obstructing progress - ultimately you're accepting more work and risk to help reduce the pressure on them to stop underperforming.
They declare the encoding in the HTTP Response.
That's totally proper. If you specify it again inside the HTML, are you gaining anything?