It depends. For stuff like npm packages, where the downstream consumers have to make a conscious decision about whether to adopt the update or not, I absolutely think it's worth getting it right, especially for major version bumps. I myself am the user of an open source code gen tool that does not have comprehensive changelogs, and it makes me want to tear my hair out because we can never be confident when upgrading whether or not we're going to end up with changes that will break our workflows or our customers' workflows.

But for consumer apps, honestly, maybe not? Even at companies that do good consumer changelogs, they're generally considered marketing content. Other posters in this thread made the points that most people updating consumer apps are not even going to see the changelog message, and that app stores have effectively punished companies for providing detailed changelogs by holding app store releases over them.

And given that for larger companies so many of them are actually controlling their feature releases on the backend and not on the client side (you might add the capability for a feature on the client months before you actually set the rollout to 100%), trying to convey those updates in the client-side changelog can be hard to do in a way that consumers will understand and can often generate a lot of confusion and support tickets. After all, we don't expect a changelog entry every time a website updates, and I feel like every day mobile and desktop apps are getting closer and closer to that category.