IMHO it depends on whether this "workflow" (the flow of pages in the applicatoin) is static, dynamic, or is expected to change but rarely.
If the flow is static (known at compile time), then it wouldn't be worth it. If the flow changes constantly, unless you can encapsulate that dynamism at compile time with workflow, then probably not.
But, if the flow changes per installation or per client yes. An example would be that the flow of documents depends on the outcome of, say, a business analyst's summary. It would be different per client, and so a different page flow would be designed using workflow and then plugged into the system.
It seems to me that you fall into the middle range. You have a well known process that may flow through a number of different steps depending on the status of an order. Your choice will probably be determined by the difficulty of implementing your page flow as a workflow and the ease of describing the process using out of the box activities.
I'd suggest creating a simple (such as a 3 step process) website that uses workflow for page flow. You'll soon find out how hard/easy it is to describe and control page flow using WF.