And anyway, I disagree with that it's an anti-pattern. If you want to capture information about each step of a process, SQL Server (or any RDBMS) is great at that. However, if what you want is a workflow that your RDBMS is facilitating, and you really don't care about the intermediate steps, you just want to make sure it gets done, then there are a lot of workflow systems out there that do a great job. I'm also a big fan of combining workflow software with logging the steps to SQL Server for a straight-forward process.
But again, it depends on what data's being stored and what types of queuing you're doing. One project I've done that comes to mind is to take multiple sources, grab the changes, then store the combined, conformed data in an operational data store, while flagging the rows that were changed. Downstream systems then pick up the changed rows based on their last run and pull those changes down--completely oblivious to the fact that multiple sources are coming together. In this case, you could abstract it away to the fact that it's a queuing system, but there are multiple inputs and multiple endpoints, so a persistent store with that data is paramount.
[1]: http://en.wikipedia.org/wiki/Multiversion_concurrency_contro...
