Disclaimer - I work for Riverbed as an SE.

The others describe it accurately. It all depends on your traffic and situation, none are the same.

I do Federal work - with lots of disadvantaged branch sites on sub-1mbps SATCOM. There is need to get mission done and no way to get more bandwidth.

In this case, WANOP is invaluable and is the reason the site works.

If you've got a branch site 50ms away and can get a big Metro-E circuit, then no.

Nice thing about WANOP is that you choose which sites need it, and if they don't, they don't get one.

WANOP was also important with applications that weren't tuned for latency, like CIFS/SMB, Sharepoint, etc. If your traffic is all encrypted such as SSL, and you can't get the certs, then it's not as helpful.

A last note is that they're very visible when things break - most network engineers get the "it's the network!" finger pointing pretty easily. With WANOP - the magic box that nobody understands gets blamed immediately. You have to keep code up to date or it breaks things. The protocols change a lot - so appliances need to be changed with them.

If you're not seeing much value (as you said, you used inpath rules to bypass traffic) I'd suggest making your SE do some work. Find out if steelheads could be configured better or you're missing something. Get a brief of recently-released features that could be useful to you. Make him give you a roadmap to see if there's anything coming down the pipe that could be useful.

The nice thing about being the SE, and not the Rep, is that I get paid to be the good cop - I'm much more interested in the customers and their mission. If it's not going to work or it won't provide much value, I'm not putting anything in the path that could break and degrade anything.