I've used Service Broker in a single server setup in conjuntion with a .NET service application in two different scenarios.

In a manufacturing scenario, a machine-to-SQL interface ran a stored proc on the server that sent a message to the service broker. The interface kicked off the proc every time the machine reached a certain state based on its sensors. The service app ran a listener thread that received messages one at a time and performed the work, in this case, messages sent out the serial port to other machines. Since serial ports are slow, the work had to be queued. The SQL Server had other functions in this scenario--I wouldn't have used it just for queuing, but it certainly was handy for that.

I did something similar in a work distribution system. Messages containing work orders arrived via a web service that ran a procedure that sent a message. A .NET service ran a listener that matched available workers with work orders and it pushed the work via TCP to individual workstations where employees made phone calls to complete the assigned work.

In each case, the service app could have maintained a queue in memory, but SQL Server provided a robust and reliable queue and an interface for adding to the queue.