As many posters have pointed out, there are about a gajillion ways to do this (I'm a big fan of GRE, Quagga, and some judicious OSPF metrics :)

If you're talking about remote offices with workers who aren't IT-aware past "Oooooh, email" and you start adding layers of complexity to their Internet connection(s), you necessarily increase the risks of network downtime due to configuration errors, busted hardware, code bugs, etc... many times things you can't fix remotely. Some assessment of your target customer's tech-level for dealing with those issues should go in to the design decision. E.g. - implementing a Linux-based firewall on repurposed commodity hardware in an office without full time IT staff might make for a nightmare if the hard drive died; you likely would end up driving to that office to fix it, hiring a local "consultant" to assist if you can't drive there reasonably, or re-tasking someone's time in the office for your own nefarious IT purposes (instead of them being out there selling your employer's bread and butter).

If you're a centralized network manager at the company HQ, then the conversation that starts with "Powercycle the blue-and-white box and tell me what the LED's do" is a lot easier to deal with than "What does the screen say? Oh, well a kernel panic means something really bad happened..." You can mitigate those issues, but you'll inevitably end up on the phone someday with an office worker whose "Internet ain't workin". Sometimes it's easier to spend the money up front for a piece of dedicated hardware, rather than in the back-end on support costs (opportunity or actual).