I worked at a mass notification company that used a similar approach and it worked well with a handful of workers pulling in batches that could push out 300 to 500 of messages per second and could queue a quarter million messages in a few seconds. There wasn't really a need to optimized past that since the throughput on the rest of the system was the bottlenecked by outside components.
The problem with queuing in {insert new hot queueing system} is that persistent and failover support is often weak. They are by default are more efficient and simpler than RDBMS. If you're running Snapchat, Redis or RabbitMQ or whatever is entirely reasonable.
The fact that investors are putting up the money means there is some hope to the business. Not every startup gets that ...
People seem to really focus on the negative. Startups are known to be bimodal outcomes. Either you retire from them or your income is down a few years. If you don't believe in a specific startup, don't work for them. If you don't believe in any startup, go work somewhere else.
Facebook has tried copying Groupon. This is their Groupon Now! clone announcement (http://www.facebook.com/blog/blog.php?post=446183422130). www.facebook.com/deals appears dead so not sure if they've abandoned the project entirely.
Netscape no longer exists as a company (or meaningful subdivision of AOL) so that might not have been the best strategy. Copying got them ahead quickly but didn't keep them there.
The data is also skewed with false positive whereby the company appears alive but is not. My previous, now defunct startup's domain responds with a redirect to another domain.
You might want to checkout ziplist. Most of the apps in the recipe/grocery space are pretty horrible but that site does a reasonable job, has a solid team as well as Martha Stuart as an investor. Not an immediate competitor to what you're doing but worth being aware of. I applied to YC with something close to what they've built although I wasn't aware of them when I applied.
The bigger picture is that WebSockets increases what's possible via the web. In theory REST isn't tied to HTTP although practically speaking, the two do go hand in hand. The natural REST application is also somewhat different from the natural WebSocket application.
The problem with queuing in {insert new hot queueing system} is that persistent and failover support is often weak. They are by default are more efficient and simpler than RDBMS. If you're running Snapchat, Redis or RabbitMQ or whatever is entirely reasonable.