Uh...these routers aren't "smart". They're doing the bare minimum to get a packet from an input interface to an output interface.
Basically, ANYTHING you try to do at the speed and scale you'd end up needing to use these routers for would be at least as complicated if not more so.
The level of engineering required to de-encapsulate a packet, deal with the L2(Ethernet),L2.5 (MPLS), L3(IP) headers, perform a lookup in the appropriate table (might be more than one), possibly deal with any encapsulations INSIDE that packet (cough-cough GRE) which starts the whole process over again is IMPRESSIVE. You're not going to do that in software, my friend. And anything you build that even begins to look like a general purpose processor will be unable to perform to the degree to which the custom ASICs already do.
NPU (Network Processor Units) were supposed to make this easy but they never took off so now what few remain are doing things like NAT or Application Firewalls, and doing a relatively poor job for the money compared to a reasonable x86 server with appropriate I/O engineering.
tl;dr: you're woefully ignorant about what it takes to make the Internet run fast.
I didn't say it would be fast, only that it seemed like the right place for the specific goals of multipath TCP in order to minimize code duplication and overcome the various "smart" devices (a marketing word, not an accurate description) that pierce layer boundaries (like smart switches that look at IP headers, and routers that look at TCP/UDP flows) and have effectively rendered it impossible to develop new protocol semantics in lower layers (because they won't make it across the Internet; IPv6 could be depolyed by now if lots of ISPs didn't have "smart" devices blocking everything but IP+TCP+some special types of UDP). I blame such devices for making it unnecessarily complicated to develop multipath semantics over the current Internet.
Uh, you don't know what you're talking about. ISPs dont block UDP. And IPv6 was held up by a lot more than hardware. Sorry.
Go read up on how IP routers actually function and then report back with what you've learned.
Source: I've been doing this (networking) since before there was an Internet. I currently don't touch routers that do anything less than 10Gbps/port and really prefer to work with 100Gbps/port. That's a cool couple o'million bucks per chasis, yo.
Basically, ANYTHING you try to do at the speed and scale you'd end up needing to use these routers for would be at least as complicated if not more so.
The level of engineering required to de-encapsulate a packet, deal with the L2(Ethernet),L2.5 (MPLS), L3(IP) headers, perform a lookup in the appropriate table (might be more than one), possibly deal with any encapsulations INSIDE that packet (cough-cough GRE) which starts the whole process over again is IMPRESSIVE. You're not going to do that in software, my friend. And anything you build that even begins to look like a general purpose processor will be unable to perform to the degree to which the custom ASICs already do.
NPU (Network Processor Units) were supposed to make this easy but they never took off so now what few remain are doing things like NAT or Application Firewalls, and doing a relatively poor job for the money compared to a reasonable x86 server with appropriate I/O engineering.
tl;dr: you're woefully ignorant about what it takes to make the Internet run fast.