Multi-user token works fine, and is indeed useful when debugging different projects at the same time (for teams). That's the way we are currently working.
The security issues I find more relevant are focused in internal networks, but they can be even more relevant towards a public server (honestly I find that a public server is just too much of a risk):
* Privilege escalation
Usually people run weinre on a developer-device perspective, and on a on-ocasion period, so it doesn't stay running at all times. Thus usually people don't mind running weinre as a privileged user. However on our particular case we are running weinre as a Windows service, because our developers need to use it whenever they need. In this case (and in on-ocasion) it's important to run the server with an unpriviliged and limited account. It's not putting little faith in weinre or nodejs, but as a sysadmin I need to be a security freak (and I enjoy it =P). If a vulnerability is found in either weinre or nodejs that allows, for example, to run code in the security context of the user running the server, you'll want to make it harder and give that user the least amount of privileges needed to acomplish it's purpose (basically run nodejs server and weinre).
* Service assessment
We all like to consider our networks safe... however they might be safe until such a point. If you consider that you have an insecure computer in your network (an infected machine, or just a rogue access point some dumb employee has connected to your network) you'll wan't to defend weinre (and thus your server) from malicious assessments, like "oh, what's this service here?". In this point what we were thinking of implementing as a very rudimentary way of defense was using the boundHost feature to filter the requests that didn't use the correct address (which Patrick already told me doesn't work that way) in conjunction with passing an unique argument common to each request (like a guid as a query string). This unique argument would be defined in the script tag in the page pointing to weinre and would be passed by the client also. This would also prevent a "casual" browse of the main page, and ensure that you needed the unique argument to receive any output of the server (I would no longer just browse the service and "oooohhh, it's weinre... =P". Sure, just sniffing traffic you could easily defeat such a mechanism, but this is intended to be a basic way of protection.
A proper mechanism might pass by some sort of registering the page to be debugged (sorry, I don't know the project's terminology) with the server, having the server check if the referrer is known or not. From the client (developer) side I think plain old authentication might be enough (possibly in conjunction with https support).