I thank you for thinking of my article, @holvoetn, but I think it's misapplied in the context of this thread.
First, a nit: you'll want to remove the "&p" bit from the end of the bookmarks you have, as Fossil's latest anti-bot defenses consider this a "complicated" URL, forcing a redirect to a "honeypot" page meant to trap bots, keeping them from running up the CPU usage of the host to no good end. I don't know why Fossil puts that particular query parameter on /wiki URLs by default, but it doesn't help, and it does hurt now.
(The symptom is hidden from you, @holvoetn, because you have a login on my site, and presenting a valid login cookie bypasses this defense. When others click the URL, they get sent to the honeypot.)
Moving on to more substantial matters, while the container vs VM confusion is real, as my article goes to some pains to point out, QNAP offers both a VM feature (referenced by @mkx above, "Virtualization Station") and also a version of Docker Engine that they call Container Station. CHR should run on the first (didn't try it) but won't run on the second.
The proper application of my article's lessons here is, don't run containers on QNAP via CHR. Run them directly under Container Station instead.
As to the question of the wisdom of using a QNAP box as a router, the best objection I can come up with is, why would you want a one- or two-port router? Few QNAP boxes have more. There are other features in RouterOS besides just "routing," but then, QNAP's OSes provide a lot of that, too. (e.g. VPNs.) Dragging CHR into the mix is likely to add complexity without adding necessary features.
I could justify CHR on QNAP for homelabbing, with the free version, but not as a real router, pushing substantial flows.