Good "starter" article, but it is far from anything new, and its a pretty simple article. I wish it went more in-depth.
22 CVEs really isn't that bad in comparison, but also depends on the severity and exposure risk.
I have been following many of them and still waiting to see how high it may climb for some of the appliances.
As jgreco pointed out, a problem can be that they don't get patched for whatever reason, or sometimes can't be.
The whole section where the writer discusses the types of vulnerabilities found "command injection, cross-site request forgery, buffer overflows, authentication bypasses and failures, information disclosure, backdoor accounts, poor session management and directory traversal", isn't that scary depending on the exposure risk. Also these can be said about pretty much most software out there, at least one or two of the vulnerabilities comes standard as a selling point half the time it seems. :)
Heck even a lot of IPMI implementations have still several of them.
Despite the fact that many appliances, SOHO devices, printers, etc are usually built to serve one purpose, it is usually the inclusion of "added features" which create the vulnerabilities outlined in the article.
On the topic of SOHO routers, some big ones that caused a stir for some people I know was the ASUS AiCloud and half baked CIFS and FTP features of their wireless routers. They were very vulnerable and sort of still are, especially when users are finding them enabled by default. HP is notorious for some of the admin/root backdoors and web interfaces that are subject to injection in their appliances, even the data storage ones. Some Dell Printer models have backdoors and are subject to easy island hopping.
Security by design is still slowly being accepted as the norm, finding that "just works vs secure" middle ground is hard sometimes. Cost and time becomes an issue for some shops when implementing security into the software development lifecycle, other times it is ignorance and laziness.
I recently dealt with an application developer who refused to reduce vulnerabilities due to cost and time. The application was riddled with vulnerabilities, but also used PostgreSQL 8.3 (very vulnerable and end of life for support). They didn't want to update Postgre because they would have to overhaul their code, instead they just wanted to keep peddling their crapware hoping someone will buy it without knowing any better.
The more vulnerabilities found, the better in my opinion. Well as long as patches come quickly after.