I ve always wondered why all computers don't have a "slow down" setting
They have, kind of, it's the energy save mode.
On Linux, (besides GPU) you'd set /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq to cpuinfo_min_freq, for all $i. I always look for minimum (idling) CPU frequency in devices before buying them, but this info is almost never available. My laptop has a min freq of 800 MHz, but I would like to go even lower, to better test low performance devices and limit energy usage. In web dev, you can simply use chrome dev tools cpu throttling though
There are two ways you can go lower: the cpu cgroup, and cooling_deviceN. I'm still working on memorizing the first approach :) but it works well just about everywhere; the second is simpler but employs intel-specific hardware-level throttling which may or may not behave usefully (it may have been the cause of a couple of mystery soft hangs on an old Pentium box I have here, presumably things are less glitchy now given how frequently laptops throttle nowadays).
While the cgroup approach is (like cpufreq) doable by poking around in /sys/fs/cgroup (you mkdir new directories to create cgroups), cgroup-tools makes it a tad more straightforward by making the steps less verbose. (Besides cgroup-tools, "unshare" and "nsenter" ship with util-linux and can issue the syscalls necessary to start a process in a given cgroup, which you can't do with pure bash.)
The setup is always the same - you create a new "cpu" cgroup (here named "cpulimit"), then configure CFS (completely fair scheduler, I think? I thought there were multiple schedulers... maybe this only applies if using CFS? I think CFS is the default everywhere) with a period and quota. I think the period is used to derive an internal tick rate. The quota is a fraction of the period and the ratio (yay you get to do the math yourself) represents how much CPU the task gets to eat. I think the ratio applies across all the CPUs. I have no idea what happens if you bring PID-level CPU affinity into the equation. Maybe you can select which CPUs are enabled for the cgroup, and the math applies to whatever's enabled. Haven't answered any of that yet. In any case:
# cgcreate -g cpu:cpulimit
# cgset -r cpu.cfs_period_us=1000000 cpulimit
# cgset -r cpu.cfs_quota_us=100 cpulimit
# cgexec -g cpu:cpulimit yes | pv -l > /dev/null
The nice thing is that the cgroup happily sits in the background until explicitly deleted (and systemd leaves everything it didn't create alone) and you can just poke at its values anytime. Network cgroups can probably do interesting fun things to traffic as well (oh yeah, network namespaces = discrete iptables/nftables per namespace).
Lastly, the cooling_deviceN entries are in /sys/class/thermal, and have cur_state and max_state. YMMV; setting cur_ to max_ may well take several minutes to undo (very much the case on older systems at least) - maybe try that on a throwaway-able session. :D (Think "Task Manager (Not Responding)"...)
When I tried your commands, on Arch via libcgroup-git, `cgcreate -g cpu:cpulimit` only results in `cgcreate: can't create cgroup cpulimit: Cgroup, requested group parameter does not exist`, for some reason. But this is not a support ticket, I have not researched this at all yet. But cgroups only limit some processes anyway, never the entire core(s) - so it seems one could also simply use cpulimit [1] instead which emulates by sending SIGSTOP and SIGCONT.
About cooling_deviceN: While this does limit cpu functionality, this seems to only also set `scaling_max_freq` to an appropriate value, throttling because the fans are disabled. Not more useful than setting the frequency manually I presume.