What you might have done is dropped the JPEG file into a text editor, which is done for a different purpose than dropping it directly into the Binder. Any type of file can be dropped into the Binder at all. You can put Excel spreadsheets in there, PDF files, interviews and whatever else you have on your computer. It will even display a fair number of formats. Dropping a graphic file into a text editor, on the other hand, will convert it to PNG (which prioritises quality, so yes will be larger than a JPEG file in most cases) and embed it into the RTF file itself. This would in most cases not be a research move, but a production move. You want that file printed somewhere with some text.
So really, we can say there are four ways to bring an image into Scrivener (one of which is only available on the Mac right now):
- The JPEG is dropped directly into the Binder. When you click on it, you see the picture in the editor. It has all of the meta-data and notes that a text file does, off in the Inspector. The file itself will be copied or mirrored into the project filesystem. No bytes will be altered!
- The file is brought in via
[b]File/Import/Research Files as Aliases...[/b]. In this case an HFS+ “Alias” is created, pointing back to the original resource, and the Alias is imported into the project in its stead. It otherwise acts just like case #1 above. You click on it in the Binder and it loads in the editor, you can open it in external editing software, add keywords and labels to it and so on. Yes, in some cases the alias might be larger than the original resource, but if the resource is that small then you probably aren’t linking it for reasons of avoiding project bulk.
- The picture is dropped into a text editor. As described above, the image is converted to the Portable Network Graphics format and embedded directly into the RTF file that is used to hold the data for that section of the binder. Since PNG is a higher quality format than JPEG, they will sometimes be larger, but you can be sure they will never degrade in quality. Meanwhile PNG is still compressed, and so while it is suitable for print, it doesn’t take up as much space as a typical print-ready graphic format. (True, TIFF is capable of compression via an add-on style system, but this is not nearly as cross-platform compatible as PNG, and probably not as future proof.)
- The picture is referenced in a text document with
[b]Edit/Insert/Image Linked to File...[/b]. In this case a plain-text URI is printed as invisible syntax in the RTF file. When Scrivener encounters this code, it requests that the operating system grab the bytes from that URI and print them in the editor as the original picture. These bytes are cached during the session, but otherwise are not stored in the project and are refreshed whenever the project is reloaded.
So, those are your choices. Options #1 & #3 are ideal when the resource in question must be portable. If it must be seen by multiple parties on different computers, or if it must be accessible to you no matter where you go, then it makes sense to copy and import the full resource into your project. Since everything is contained inside the project, the act of copying the project to another computer will bring along all of the resources automatically. There is no need to maintain relative links and mirror folder structures between computers. This is one of the reasons, in fact, that Scrivener was designed at all in the first place: to make a central working space for the writer rather than having all of these hundreds of satellite files strewn about the operating system without any binding meta-data or central navigation between them.
For the two other options, these primarily allow one to continue having full access to the resources from software outside of Scrivener. While it is easy to open a resource in the Binder and hit [b]Ctrl-Opt-O[/b] to open it in its default editor (all changes being of course saved directly back into the project), sometimes you need direct access to those resources externally. Perhaps a script comes through every night and updates the files. Perhaps the files are on a company file server and multiple people access. Perhaps you only need placeholder illustrations in place until your graphic designer gets back with you. Replacing several hundred placeholder graphics with the final versions is a few seconds of work, whereas replacing several hundred embedded graphics scattered throughout hundreds of binder text files is a job that is going to take you many hours.
Finally in some less common cases there may be a desire to use file links where a bulk of resources is so massive that would be a burden to keep it all in the project. Someone might have several hundred gigabytes of research data for their thesis, and putting all of that into the project format is unwise as it means it will never be properly backed up. This particular use case is not compatible with what you are describing a need for, with relative links, anyway. That is the type of resource you have at your home workstation, not scattered all over the place.
The above options address, in my humble opinion, everything the average writer is going to need. Those that need to have one copy of a file shared by multiple computers, that absolutely cannot have that file imported fully into the project, are going to be a small minority. We’re really talking about unusual situations here, not common working practices. For most things, Scrivener’s curated system where links are implicit and all resources travel together in a singular package or folder is, for nearly everyone, not only adequate but a novel and elegant way to solve the problem of having your writing research and WIP scattered across multiple computers.
It also, incidentally, resolves the much less common desire to have a cross-platform solution to linking (something that is otherwise fairly problematic). Since Scrivener handles the data and the linkages seamlessly, using the Binder metaphor, it doesn’t matter what computer you load the project on. On every single one if you click on a JPEG file in the Binder it will pop up in the editor.
So I think your fundamental question is: why use absolute links at all for the things that do require links? Well as already mentioned, for one of the link types it’s not even a distinction between absolute or relative. Aliases are a feature of the filesystem itself that allow resource to be permanently linked even if the file is moved or renamed. That’s better than both absolute and relative links, for most users. Yes, since it is a function of the filesystem that does mean it cannot leave the filesystem—it cannot be brought to another HFS+ based computer, let alone NTFS or EXT4. But again, given its design purpose that’s not a huge deal. There aren’t many people that need the scenario you are describing, in our experience.
Let me be clear, in most cases I do agree with you. In most cases where one needs a link to something, relative works better. In other types of programs there are other use cases, and quite often relative links are the best answer to the problem. My contention is that Scrivener doesn’t fit into that type of role, and does not have those common use cases. It isn’t the file you give your publisher. It’s not the file you give to your readers. And in most cases where two or more people do need to use the project, putting the material into the Binder is more than good enough. Keep in mind that putting this project on a Dropbox (or similar) folder and sharing it with others is just as resource efficient as sending them a project with a separate “research files” archive, but more efficient for them as they don’t have to read your instructions on where and how to set up the folder to make sure all of the relative links work. Once Dropbox has the content uploaded and downloaded, so long as that content doesn’t change it won’t be constantly travelling back and forth. Since a project is a folder format, it’s not like these resources really bloat its transmission costs, so long as the transmission agent isn’t thoroughly stupid in how it moves data around. 
Maybe, but remember you can keep your FreeMind files in the Scrivener Binder, too. But in short, it sounds like you are accustomed to a file format that must use links to handle research material. Scrivener is fairly unique in that it is a writing format that allows you to store 5 gigabytes of PDFs in it. The practices that may have evolved as a result of working with nexus formats that link outward are not necessarily applicable to Scrivener.
