Actually, even on EdgeOS, I barely use the web interface any more. Their new SPI web graphic stuff is nice, but very RAM intensive on such small boxes. And iptraf is more controllable. And logging is better done elsewhere. But it is nice, even if the current 1.8b3 EdgeOS locked up my girlfriend's router (yes, one of my "decommissioned" and she knows SPI is there, by request for other "users") in under two days, though it's been ok elsewhere on the 1.7 point release. But that's it for the GUI. Also, more attack surface, and the certificate is annoying to replace, not built in to anything, GUI or CLI, not a symlink to a persistent file in /config... and with 512MB, I'd rather it spent it on conntrack not lighttpd.
But the CLI/autocomplete/inline help is pretty fast (in fact, the only thing of use with the EdgeOS GUI is the config key "map" to show all the CLI options, but even then, setting them is faster in the CLI vbash. Say you want to copy a single DHCP scope, comprising boot options and multiple subnets; like if you were doing some sort of multitenant thing. Or not multitenant, but same network, but you'll change the subnet for each, but VoIP phone tftp options and internal DNS is the same. Only one of these exists, called foo.
ed<tab>it ser<tab>vices dhcp-s<tab>server
co<tab>py sha<tab>red-network-name <tab>foo <tab> to <tab> shared-network-name bar1
then press up arrow, erase the 1 and hit 2 for bar2, up arrow again, bar3 and so on.
Everything in italics isn't a key press.
Now you have a lot of clones of DHCP foo named bar1...
and even faster is editing config.boot in a text editor, or doing the above in CLI to make nice templates and then just search/replace. Want a failover router? Copy your running router's config.boot, overwrite the default one in a VMs, set the new IP and make the new VRRP IP where it currently is. Then boot/cable switch to that new config. Or make the commit changes to the running HW router as the new ones wait for it to join them in an existing VRRP group.
Want another? Take that new text file and paste it into a new VM and just change the inter-router and LAN IP. And a third. Bam, three failover routers. And if they are VMs, just clone after shutting down step one and change one or two numbers (literally) in a text file before plugging them into a vswitch. Or of course script it.
The only advantages right now for EdgeOS are the new routing things in 1.8b3 mostly for external labeling (which doesn't apply to me and I can't speak towards) and the resolution of a VTI/L2TP conflict that has been around for a long time, which unfortunately does, and I will not go back to IPSEC tun. (yes, GRE, I know). But it's been a little unstable anyway.
Doesn't matter. Yes, you could buy more than one Edgerouter, and have drop in spares - with service denial and hope your latest commits made it to your syslog and pull it from there. You could VRRP them, but with that cabling and ideally independent UPS/outlet/circuit chains, and with customer's services on the line, you probably have spent more than the box cost, and have a lot more in income to lose. Or you could have a roll your own Supermicro Rangeley with RAID (natively supported as part of a VyOS install) and swap a drive. Or buy a Lanner or Netgate box for a bit of middleman overhead.
Or you could virtualize the IP at the service level inside the VM across (virtual) machines and (physical) hypervisors (hell, a VyOS VM and UBNT ERL will failover on the same gateway IP just fine, let alone VyOS/Hyper-V and VyOS/ESXi) *and* the cluster/replication you get with VMs. Don't migrate them though, even across the same hypervisor, you don't want the copy time and also it may limit the advantages of any CPU acceleration benefits if you have it going across CPU architectures; let them use the native CPU features if available (and won't cause failure if an Avoton takes over for a Rangeley, for example.)
Much of it depends on what you can afford to lose with a service failure, and the cost of managing failure avoidance.
It goes without saying that spinning up some VMs is as "free" as the hardware cost of what is probably the most reliable option; doesn't change the fact that someone has to manage the juggling balls and test the redundancy.