Whenever you add or update a package, it's possible that the package or its dependences will have bugs that can affect how the rest of your system preforms. The most common way this happens is that currently working customized configuration files are over written by the default version upon installation of an updated package (the bug I mention below is a result of this).
However, especially when a user is trying to install a package that is no longer maintained, or one that hasn't yet been accepted to the general repository, it's not all that uncommon to come across dependency related issues.
The most simple form of this is a versioning issue that is caused when the package you want to install has a co-dependancies with other packages on your system that can only be satisfied by installing an downstream or upstream version of a file on your system.
While usually not a problem, package-maintainers often claim that their package has indefinite forward compatibly with packages they are dependant on. However if the maintainer of the package depended on makes an unexpected change upstream, this can break your system (and indeed has caused me problems when adding new desktop environments to saucy)
In other cases, the dependences required by the package you are installing conflict with what's already installed on your system. When this happens the package manager may ask you to remove some packages that you may be relying on in order to install and satisfy the dependencies of the new packages. This can be avoided by carefully reviewing the purpose any packages that are requested for removal.
In some rare cases where packages on your system did not adequately declare all of their dependencies, you may find some packages no longer work even though they claim to have all their dependencies satisfied.
If you always use either synaptic, or aptitude to do your package installs, then you'll have a better chance of recovering form this situation. Unlike apt-get, synaptic, and aptitude keep a log of exactly what was installed and removed, and thus allow you to easily revert to your previous state.
I have personally experienced a problem with trying to co-install Unity and another lightweight desktop environment, so I wouldn't be surprised to hear that LXDE also doesn't work well with unity installed. That said, the likely hood is low and recovery via aptitude (or synaptic provide you can still access the GUI) is easy.
Nevertheless, I found the fight to keep unity happy with openbox and enlightenment really wasn't worth it to me, especially considering the extremely slow performance of Unity's dash.
After trying a plethora of other environments and distros, I settled on KDE via Kubuntu and/or LinuxMint as a better choice to replace Unity as a full fledged desktop because it still provides access to ubuntu support channels, and overall seemes to be better suited for traditional desktop use. I do, however, still run Unity on my lower powered netbooks/nettops/tablets where I'm less likely to use dash anyway.