Definitely an interesting editorial, and a question well worth asking. My answer is look at the requirements and see whether it will be better to use a database (not neccessarily a relational database) or to just use one of the available messaging systems. Of course not all queues are for messaging, but I get the impreeion both from the editorial and from comments here that messaging is really what the editorial was addressing.
call.copse (2/3/2016)
I think is SOMETHING of an anti pattern - sometimes though the reverse is true and breaking out another technology is premature optimisation, the SQL based solution is more than adequate for the job. Particularly say a queue where you don't need to do so much inserting, updating and deleting, where your queue is a pointer to another record and the pointers are just added and deleted as required, without a whole lot of throughput. It all depends really.
Oh, it's actually much worse than premature optimisation - it's choosing the soluion before studying the requirements.
I've had queues in a database, in cases where the requirements could probably not have been met by a messaging system. Requirements like "A, B, and C must either all get into the queue or none of them" which are trivial to meet using SQL server are nigh on impossible with most messaging systems (or atleast they were a few years back, I guess I'm out of date now). As soon as you add to that a requirement like "message B must not be transmitted to its recipients until message A has been acknowledged by at least wo of its recipients" you are pretty well stuck with building some nice persistent data-structure that will be manipulated in transactions, so is you don't se a DMS you will have to reinvent that particular wheel. Distinguishing messages that require acknowlegement (by a human responding) from those that merely require confirmation of delievery (by the destination mailbox, whatever that might be) and from those that should be deleted at the source as soon as they are transmitted (ie acknowledged by the first relay in the messaging chain) is useful. Specifying earliest permitted transmiaaion time for a message may be required for some messages, or for all messages, or not required at all. Target time for transmission and priority may be required. All of polling, direct or trigger-based activation, and activation based on queue length are all possible requirements.
So a simple fairly brain-dead messaging system may not meet the requirements at all, and trying not to use a DBMS may cost a vast amount of design and development effort. On the other hand, if the requirements are simple and don't require anything other than high and sufficiently reliable message throughput there's probably no point in involving a DBMS.
Tom