Sorry to keep you all waiting, I was away from the computer for a few days.
I have done a lot of test on this in the last few weeks, pretty sure I know what is going on.
Let me try to explain what is happening...
The issue
The simple answer is that the system is stuck in either a low performance mode (to save energy), this is the case with ARPL. The opposite is true for TCRP, in which it is stuck in a higher frequency mode.
The core of the issue lies in an add-on called misc. This add-on performs a couple of checks about the CPU the disable certain kernel features, to prevent a crash if not available. One of them is checking for the ability of the CPU to perform performance scaling. In other words it's checking for what Intel calls SpeedStep, don't know what the AMD calls this feature.
The performed check doesn't work like intended and is flawed in my opinion. It checks for features in a device directory, which don't exist at that point yet. The result of this is that the kernel module called acpi-cpufreq is not loaded. Once loaded the directory is populated. This issue was previously reported, I guess the consequence wasn't realised.
This acpi-cpufreq module manages performance scaling with a governor, there is more than 1 but the default governor on the models I've tested is called performance. When there is no load the governor scales the CPU down to save energy, and scales up again when there is a need for it.
All models that include the misc add-on are effected by this missing module, even the 3615xs. Although it loads the acpi-cpufreq through another kernel module called mperf, this results in a normal experience. It might be possible that different models use different governors, but once the real issue is fixed it loads the preferred governor anyway.
Loader differences
Why is there a difference between the loaders? I'm not 100% sure about this, but I have a very plausible idea. Since the DSM system, doesn't start by itself on anything but Synology's hardware, we need a loader to perform a couple of steps, before it turns over to DSM. These loaders, ARPL, TCRP or Jun are by them selfs systems with its own kernel. This means the loader manages this performance scaling and then turns it over to DSM.
The difference in performance between ARPL and TCRP might be the result of this. The ARPL loader sets the performance scaling into the userspace governor, with the minimum frequency, once in DSM and unable to scale it up because of the missing kernel module, the result is the low performance. I've force ARPL into a higher frequency and loaded DSM and the result was the higher stuck frequency in DSM.
TCRP starts with a different governor and seems ok, but also has the missing kernel and the result is it doesn't scale down. When using TCRP withfriend it has the same low performance as ARPL, which proves this even more. On a real Synology or even perfectly working XPEnology NAS it might seem it not scaling, but it definitely is. You just need to look in the right place.
Fixing the issue
It's not very hard to fix this issue. There a several ways of doing this, the best way is to put in place better checks in the misc add-on so everyone benefits. I have a couple of ideas for this but I need @pocopico and @fbelavenuto to give me a better idea why it was implemented.
Right now I think it's really just needed on hypervisors, where I replicated the issue with a crash. Since the host of the VM manages the CPU, there is no performance scaling inside the VM and all modern CPUs should be able to do so when running bare metal.
Temporary fix
Right now I would suggest to go with a temporary fix (for advanced users only), which needs to be re-applied once restarted. This has the benefits of getting things up again, might there be a crash on your system, which this check in misc is trying to prevent.
This needs to be run in the shell as root, if you don't know how to do this, I don't think this is for you right now. I have done my testing on an isolated drive, with ARPL but TCRP should work too.
If you do this make sure you have an idea what you are doing, there is always a risk of losing data if something goes wrong.
modprobe acpi-cpufreq && echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
The modprobe loads the kernel module and on success it forces all the governor into performance mode.
Once loaded you can check if you get an output.
grep . /sys/devices/system/cpu/cpu0/cpufreq/*
Hope you guys find this helpful, and appreciate the work I have done. Aswell as what the people working on these loaders do, mistakes happen, please don't blame anyone.