RouterOS in fact is Linux, so have you tried to track and follow Linux Kernel changes? full -yes! comprehensive - hell no!
I'm not 100% sure where you are going with this line of argumentation. Are you saying that the Linux kernel, a very high-profile open source project, doesn't publish a comprehensive summary of all changes made, so if a project like that can't manage to do it, how can we expect MikroTik to do so? (In other words, you are saying an expectation of a comprehensive change summary with every release is unreasonable.)
Or are you saying that many of the problems that RouterOS users experience are in fact not the fault of the MikroTik developers, but can be directly attributed to changes being made upstream by the Linux kernel developers? If you meant the latter, I'm pretty sure you are wrong, since from what I can tell, MikroTik sticks with a particular version of the kernel source throughout the entirety of a single RouterOS major version. RouterOS 5.x was kernel 2.6.35, from 5.0 all the way through to 5.26. RouterOS 6.x is kernel 3.3.5, all the way from 6.0 to 6.22. MikroTik devs might be making changes to the kernel source tree, either via self-developed changes or by applying patches developed by others (backports of bug fixes from later kernels, maybe), but they aren't switching kernel versions in the middle of a release cycle, so although perhaps bugs that were introduced between 5.26 and 6.0beta1 can be blamed partly on the new kernel, regressions within the 6.x series cannot.
Also you can't show all changes to customers, especially in case those are related to new/unannounced hardware or feature.
Okay, support for new hardware, sure. I'll give you that one. But new features, I would argue, should not be shipping on existing stable release branches, especially if you have to make changes at the core to support the new feature that could cause regressions to occur in other already existing parts of the system.
For example, in my opinion, the big PPP changes made between 6.7 and 6.8 should not have been shipped with 6.8. It could have been released as a separate package, like 'ppp-test', for those who wanted to try it and help test it, or it could have waited until 7.0beta1. The same thing goes for the change from stores to disks in 6.20. There is almost no good reason to ship that sweeping of a change in 6.x and not wait until 7.x. The only exception I can even think of that I would be willing to allow for is if the existing 'stores' feature were broken in some fundamental way that was actively impacting users, and it was determined that the problem cannot be fixed with anything other than a from-the-ground-up rewrite. Even then, I'd say that's really pushing it.
Most of the people who are asking for a comprehensive summary of changes from release to release really aren't even talking about the kinds of things you bring up, though. Often MikroTik will make a change themselves to a version that they know about and that was done in direct response to a ticket that a user opened with them about a bug, and the fact that this bug was fixed will not make it into the release notes. That
is the kind of thing that people are talking about here.