The first two vulnerabilities (private link password bypass and HTML injection) seemed to occur because a single point was not being used for actions. If the link was viewed through a particular API, then the document could still be viewed (without a password)! Additionally, the HTML injection was only possible to inject into the username only when uploading with a CSV file.
The second to last bug is very interesting! Dropbox wants to loud the document 'byte for byte' while getting it secure for other users. Obviously, XSS could be devastating in this context. So, the domain dropboxusercontents.com is used in order to execute the XSS in a useless origin, protecting unsuspecting victims from potential compromise. Seems like a good thought, right?
Somebody found a crazy bypass to this with a little known browser feature called App Cache Manifest (ACM). The ACM is used in order to tell the browser which files to cache locally. Using the App Cache Manifest allowed for pages to be loaded within the normal Dropbox domain, making XSS very impactful. They abused a feature in the ACM with a fallback mechanic that allowed for pages to be loaded when something else failed.
I found Dropbox including the mitigations to be really interesting too. They have an insane amount of defense-in-depth in order to mitigate the impact of the vulnerabilities before they even happen. For instance, they have extensive jailing put in place that restrictions the length of connections and which syscalls can be used.