Linux not only has an excellent, well-understood API and management toolkit, but it also has the networking model and features essential to a modern data center. For example, Linux clearly separates the control plane (in user space) from the packet forwarding plane (in the kernel). Furthermore, it explicitly models the RIB/FIB separation too, leaving the FIB (Forwarding Information Base) in the kernel and allowing the RIB (Routing Information Base) to be managed by a user process such as a routing protocol daemon. Linux supports all the typical features you'd expect of a networking gear: IPv4/v6 support, bridging, routing, link aggregation, and so on, as well as advanced features such as BGP policy-based accounting and BGP TTL security.
Let me define what I mean by Linux as the router (or switch) OS. Specifically, I mean I do not want to modify the abstractions and API offered by Linux to the applications. Getting even more specific, Linux exposes mechanisms to access interfaces, routing table, arp cache, the L2 forwarding table, and more; it provides a notification mechanism (netlink) to receive notifications on changes to these tables; it provides mechanisms to examine the counters associated with these entries. When I speak of using Linux as a router OS, I want these to be unmodified. In short, I propose that the Linux kernel is where all the state resides.
Furthermore, instead of routing customized shells such as JunOS, NX-OS, or EOS, let's use the native Linux shell such as bash. Unlike its routing cousins, bash is not modal in nature. Each command is stand-alone and is explicitly designed to work in tandem with a chain of commands to accomplish a task. This means that scripting on a Linux OS is native. The Linux shell is designed to be a programmatic interface.
This accomplishes two things. First of all, the system is far more transparent because the kernel data structures can be examined using native Linux tools. Next, it is now possible to treat the router OS as nothing more than a megaserver -- that is, a server with 64 or 128 NICs. The circle is complete. The router is back to where it started: a Unix server with multiple NICs.
The consequences of choosing Linux
An easily noticeable effect is that the server management toolkit is now available to manage networking gear as well. Data center admins are used to managing tens of thousands to hundreds of thousands of servers. They use tools such as Ansible, Chef, and Puppet (or even in-house management toolkits) to do so. They can now use the very same tools to manage networking gear too. Unifying the management toolkit inside the data center comes with an immediate reduction in opex because admins have to be trained in only one set of tools. Furthermore, scripts written in a shell or Python or Ruby or any such language are also usable on networking gear.