It isn't a big deal (yet!). I doubt it will be an issue for running third party apps in the long run, but more on that later.
Docs to grasp the architecture of Mediatek secure boot:
https://mediatek.gitlab.io/aiot/doc/...cure-boot.html
That's probably what Kobo or its OEM follow for this board.
The key is to understand that secure boot/verified boot is a chain of trust that starts in BootROM and can go up to the root filesystem, efectively locking the system if that's the intention of the manufacturer.
On a regular computer the chain of trust ends with the 2nd stage bootloader, which needs to be signed with Microsoft approved keys.
On chromebooks it goes up to the root filesystem via dm-verity.
The way chromebooks and android implement verified boot is the "standard" way on linux OSes and the route to follow for third party OEMs. If kobo wants to do this they need to:
1. pass the hash key of the read-only rootfs as a kernel command line argument (thus available in /proc/cmdline)
2. the kernel will then verify the block device isn't tampered.
That's doable and there's nothing wrong with it but there're other clues that would point they're trying to achieve verified boot on kobos:
A/B root: because updating anything in the AP, such as the final reader application, involves, at least, a new hash for the new rootfs. Things might go wrong with an update so the ability to fallback to a previous version is a must in those cases.
Two kernels: even when kobo rarely updated a kernel on a production device, you must want two slots for two different kernels (even if both contain the same) to implement A/B root properly.
Two root filesystems.
Even with a full chain of trust up to the linux userspace, that doesn't mean the device is locked (the kernel really is!). It is up to the the manufacturer to provide a different, not "dm-veritied" filesystem for storage persistence. Overlayfs might also be used to make a regular linux system to play nice with read-only rootfs.