It'd rather reduce complexity. It'll make Go code less ambiguous leading to fewer bugs that you'll have to spend your time debugging. When working in big teams on big projects you better describe your intentions clearly.
Yes, you can hide state behind interfaces and opaque types, but you don't take into account, that the implementations of those types and interfaces need to be reliable as well. An interface with read-only types, for example, can declare its methods immutable enforcing an immutable receiver type on the implementing functions which makes sure that it's always correctly implemented and doesn't mutate its object for sure! A field can be declared immutable to make sure it remains immutable after the object is initialized, and so on. Immutable types allow you to better express your intentions when implementing something because in a month from now you'll be a different person too and you won't remember certain implementation details like "why you shouldn't mutate this inner slice in this struct" etc.
The whole concept is actually composed of 5 fundamental rules that are relatively easy to pick up. It also shouldn't be compared to C++ or even C style const qualification, because it's easier and safer.
