I too basically disagree with the author (for reasons I'll go into below), but I think it's worth unpacking a little further that high quality release notes
can form an important part of your communication strategy with your users. Note: high quality.
Many years ago I worked for a tools company where, for our less popular tools, user count would be in the thousands to tens of thousands, and for the more popular tools, it would be in the hundreds of thousands. Every single time we put out a release you could guarantee that a handful of people would ask for release notes even though we'd always publish them. Clearly people wanted them.
Now I work for a company where our platform caters to two very distinct groups of users - one group internal, the other external. Particularly for the internal users release notes are hugely important in order to avoid disrupting their work and deliverables to customers.
In both companies we've often had an "additional bug-fixes and performance improvements" item in the list.
Why?
Because people only have so much attention to go around: they're busy and, particularly in my current role and with our internal users, it's critical that we draw that limited supply of attention toward the most important changes. That's much more valuable than sending out an exhaustive document of every single change every time we do a release. We've found that if we supply exhaustive notes, fewer people tend to read them, and we get complaints that they're too long. As you've already suggested it comes down to ensuring that the release notes you provide are actually valuable to users.
Together with other documentation and training materials, release notes can provide a useful jumping off point for learning how to work with changes and improvements to our software.
(Not everybody reads them, of course, but having them does at least mean that when they inevitably ask for help/information, we can point them at the release notes as a starting point.)