I doubt that’s of any concern, that isn’t how the relationship between Scrivener and Dropbox works. Really you can better think of the relationship between the two as there being two different programs that read and write files to the same rough area of the drive. Imagine if you have a file viewer on one side of your screen and an editor on the other. Whenever you save in the editor, the viewer updates and shows you the result. At a narrow technological level, the relationship between software saving files and Dropbox reading and uploading them is pretty much identical to that. It’s more likely we’d see the opposite, where the writer is adding data so fast or in a way the viewer doesn’t expect, and causes the viewer to lag trying to keep up, or malfunction. But that is where our analogy kind of breaks down anyway, since Dropbox is a viewer only in a very basic sense. It really doesn’t care what the bytes are, just that they are different now and need to be uploaded to the server.
Now if Scrivener were something that read changes from the disk in real time, then in theory it could get jammed up if something else changed a bunch of its data beneath it, but it’s not. It blindly writes to the disk, and thus it is almost impossible for a “viewer” to trip it up.
If the images are not stored in the documents, then it is unlikely they are of any impact to performance. Stuff that might make them factors are viewing large quantities of them on a corkboard (consider disabling image thumbnails if you do that a lot), or going through them one by one in the main viewer. But if you don’t do anything to view them in any way, they might as well not even be in the project for all of the impact they don’t have.
The one red flag I did see in your “slow down” sample is that Scrivener peaked at 3.9gb of RAM usage. There is definitely on the high end, and could indicate you’ve done a lot of media import or browsing recently. It could also indicate you’ve compiled a particularly large project recently. With numbers like that, I’d encourage being a little more wary of usage, close the software more often between sessions, and after working in very large projects. It’s generally not necessary to pay attention to things like that, but 4gb isn’t typical for something that isn’t doing 4k video editing or similar. And depending on how much RAM you system has, some of that slow down may have been excessive disk swapping, to compensate for a lack of sufficient physical RAM to keep everything running.
So what I would do is leave Activity Monitor running on the RAM tab, and keep an eye on Scrivener’s usage as you go about the session. It should start out with nothing open, pretty minimal (maybe a bit less than 100mb). If you open a large project, it may spike up a bit, but pay attention to it whenever you do something that you feel might involve a lot of data. Loading huge Scrivenings sessions and so on. What you’re looking for are cases where something causes a large spike, and then that memory use is never reclaimed normally. Ideally the memory use should always go back down to roughly how much it was using when the project was opened, it may sometimes take a minute or two to get there, but if it goes up, and just keeps going up, there could be a memory leak and that’s ultimately what is causing your system to slow down.