Good question. Now, I'm not super familiar with either project, but from what I gather they all have a server that runs on a pi or computer and connects directly to the bot. I think the biggest difference between BotQueue and Repetier Server or Octoprint is that there is not really a server on the bot itself. The print server is located at BotQueue.com, and then you have clients that connect to this server to request print jobs and execute them on the bots.
This has a number of advantages - first off, you can control your machines from anywhere you can access BotQueue.com, regardless of whether you're on the local network or not.
A second advantage is that since the clients connect to BotQueue.com, and you connect to BotQueue.com you don't have to deal with any sort of router crap like NAT and the like for external access.
A third advantage is that you can have multiple bots pulling from a queue that are not on the same client or not even in the same physical location. BotQueue was originally designed to control large fleets of machines, and I knew that it would be impossible to have 20+ machines controlled from a single computer. This allows you to manage them all from a single unified interface.
Of course there is a major flaw here - if the internet goes down, then your bot cannot communicate to the server. I live in China, so this is a pretty constant problem for me and I've written the client software to be extremely robust. It does download the entire job at once so that even if your internet is shut off during a print, it will finish the print and wait for internet comes back up to mark the job as done.
The other major disadvantage is that the communication goes through the botqueue server so it is hard to do things like realtime communication of things like temperature data or webcam stuff. There is the potential of fixing this with websockets, but I'm not sure yet. I definitely plan to address this.
The last big difference is that there is not bot control panel in botqueue yet. I plan on adding this eventually, but until there is realtime communications between the browser app and the client machine, this would just be super frustrating and slow (latency of 1s - 30s). For me, this isn't a problem but I can see some people not liking it. If I need to do some manual stuff like set temperature and such, I generally just connect over USB with pronterface / repetier, do my thing, and then re-connect it to the botqueue device.
Last, but not least, I wanted to point out that both the client and server for BotQueue are both open source. You could potentially setup your own server locally or on the internet that provides the same service. I run BotQueue.com because I want it for myself, and I think there are some really interesting things that could be built with a community of people and connected digital fabrication devices.
Anyway, I hope this answers your questions! Sorry it turned into a wall of text.
