I wrote release notes for operating systems and compilers for nearly 40 years, and it was never an easy task. New features aren't the issue - they're usually straightforward to describe. It's bug fixes that sometimes had me tearing my hair out. For each one, based on the developers' notes and (sometimes) the original problem description, I had to figure out what I could tell a reader that would help them recognize the exact problem that was fixed. In many cases, the problem was exposed only under specific combinations of uses (especially for compiler bugs), and there was no clear-cut way of describing these.
Worse, from support and development's view, were customers who had not reported a problem themselves, but saw a description that vaguely matched what they were seeing and they'd complain that "the bug wasn't fixed". Of course, THEIR version of the bug was different from what was behind the release note.
The primary purposes of release notes, in my view, are to highlight changes in behavior or requirements that users need to know about. Lists of bug fixes are a high-effort task for low user benefit, and indeed my former employer stopped providing bug fix lists in recent years.
The little snippet release notes for apps are very vague summaries of changes, and I don't at all blame developers from writing "Bug fixes and performance improvements" over and over. Yeah, the entertaining notes are, um, entertaining, but I agree that they're more a promotional thing than an attempt to educate users.