At least these lines are _IN_ changelog.
Sound to me like: "you can be glad that we even list changes in the changlog, ingrateful user!"
Every line in there is important to somebody.
Of course any line is of interest. But why is a change to a default firewall rule not a special attention required?
Here some samples of changelog entries that are of interest, but do not require special attention by a major audience, because they are informative and require no user-intervention. Mostly any entry "fixing a bug" is not of any special attention. Users that experience bugs and wait for a fix - they look out for their bugfix changelog entry.
You need to read/see a changelog from the point of view: imagine you are the device admin. You read the changelog to see what you can expect from the update. The positive aspects (bugfixes, features) as well as the negative aspects (breaking changes) and really important changes (security related) when you can't postpone the update.
*) supout - added PTP section;
*) leds - added "dark-mode" functionality for hAP ax3 and Chateau ax series devices;
*) leds - fixed modem LED indication for SXT LTE 3-7 (introduced in v7.13);
But there are changelog entries, they are in fact "breaking changes" (behaviour changes, call it how you like). An example:
*) fetch - require "ftp" user policy;
Of course this may affect not the majority of users, but this change broke scripts of several users. Just a regular change - not special attention required according to the "*" marking.
*) defconf - fixed firewall rule for IPv6 UDP traceroute;
Just informative? No diff. How should someone know from this changelog entry, that a potential firewall leak was closed? It isn't marked as "!" nor does it communicate the severity or the actual change. Just "fixed something". Could be an inefficient rule as well or a non-working rule. The rule was working, but it was too loose. Kind of important. don't you think?
*) system - improved handling of user policies;
I like to take this example from 6.49.7. Because I think it shows the root problem of these changelogs. Though the issue, that was fixed here, required admin rights on the device, and normis compared it to "thats like rooting your own phone when you already are the owner".
No it is not.
With 6.49.7: some bad person can have/gain admin rights and any change this user/admin makes is getting logged. Of course the user can "wipe" the traces by flushing/clearing the log and history. But if you have remote logging you would realize. And even then, the admin is limited to make ROS "allowed" changes to the system. Can mess up configs and so on. But once you identify the intruder, you change the password or disable the user and restore a config-backup. Done.
Before 6.49.7: one with admin user can gain access to the underlying system. Can place any binary on the device and make it run as a service. Can be of any type. Used to spy on your network or even hijack the device for a botnet.
All we possibly would see in log if at all: "user x logged in from IP". maybe that's all the traces we would see. But system compromised. No reset-configuration helps. Netinstall the only way to decontaminate. But how should we know about this dramatic severity? We can't - because it was disguised in a "improved handling" changelog entry.
I hope you get the feel for it now.