You may want to think that statement through a bit more.
Secure boot, as the name suggests, secures initial loading of the most central/core parts of an operating system: (indeed) the kernel and kernel modules.
While APTs can be installed on different levels, anywhere from kernel up to user space, a good (hard to detect) place for those is inside the kernel itself or in a kernel module.
Secure boot is definitely intended to prevent APTs, even if its only a part of the the full equation. You still need additional tools on top of a kernel, e.g. SELinux or AppArmor, that monitor, audit and (hopefully) prevent the introduction of APTs. However, without a trusted kernel (and kernel modules), all of those tools can be compromised/circumvented, making it ultimately an impossible task to secure the system as a whole.
After reading it again, you may indeed be right. I didn't see it the first time around. My bad.
Still, "installing APTs" as a synonym for installing packages with apt? I guess I would have noticed it, if it had been "installing DEBs".
Also, using SELinux or AppArmor to disable the ability to install packages with apt is a new thing to me. But I have to admit that I'm not an expert at either.
Secure boot doesn't disable installing APTs, it disables installing kernel modules.
If you want to disable apts etc, you need SELinux or AppArmor or equivalent.