Yes, you probably don't want to run untrusted code with root privileges inside a container if anything valuable is running on the same host.
However if that code is trusted, or if you're running it as an unprivileged user, or if nothing else of importance is sharing the same host, then I would not hesitate to use them.
Containers are awesome because they represent a logical component in your software stack. You can also use them as a unit of hardware resource allocation and multi-tenancy, but you don't have to: you can map a container 1-to-1 to a physical box, for example. But the logical unit remains the same regardless of the underlying hardware and multi-tenancy setup, which is truly awesome.
you're trying to justify the use of lxc for security, IMO. Your webpage does state "strong guarantees of isolation"
if you're sharing nothing of importance on the host, then, you don't really need LXC, unless you don't know how to setup mysql with more than one database, nginx with more than one virtual host, yada yada.
Here's the trick: you CAN use LXC and SUPPLEMENT it by something providing security such as SELinux.
LXC lets you use cgroups, i.e. setup memory/cpu/IO limits per container. If you setup MySQL with more than database, you can't do that.
Also, we DO use LXC and SUPPLEMENT it by something providing security such as GRSEC (in the current version in production at dotCloud) and AppArmor (with docker) :-)
if you do use apparmor and grsec (as in RBAC's part of grsec in particular) it's probably acceptable, but I haven't seen it mentioned on the website - and people figure, they'll just use lxc "and be safe".
When they were tired about seeing their patches rejected from the mainstream kernel, they decided to try a different approach, and that approach is LXC. In other words, LXC is a reimplementation of OpenVZ concepts by almost the same team.
LXC is actually more secure than OpenVZ, if only because it went through more scrutiny than OpenVZ.
Are you sure? I think LXC was developed by IBM. Team OpenVZ is still sticking with very old kernel releases (2.6.32 at most), they may adopt LXC for some of their features but they aren't very keen on upstream work.
Yes, you probably don't want to run untrusted code with root privileges inside a container if anything valuable is running on the same host.
However if that code is trusted, or if you're running it as an unprivileged user, or if nothing else of importance is sharing the same host, then I would not hesitate to use them.
Containers are awesome because they represent a logical component in your software stack. You can also use them as a unit of hardware resource allocation and multi-tenancy, but you don't have to: you can map a container 1-to-1 to a physical box, for example. But the logical unit remains the same regardless of the underlying hardware and multi-tenancy setup, which is truly awesome.
EDIT: details on multi-tenancy.