First, unreal/unity work at a different level of the hardware, and they have to deal with different graphic drivers, in the same type of the OS.
But keep in mind that they are not the end product! The end product is the game that run on them.
So, the cost to building a multiplatform game, is having a whole Game Framework (which are whole companies), to deal with the lower level details and help abstracting out the differences of the platforms.
Dropbox is the end product. So, to make the code shareable, they have to build something like the equivalent of a game engine....
which is not a simple task....
I have worked at Spotify, and we had a lower level library to help (built in C++) to help out with some of the common features across platforms. It was ported from the desktop app, to iOS and Android, and it was a separate project. Over time, as features kept piling in, it turned into a giant un-manageable mess. It got so bad at some point, that we had to skip a couple of scheduled releases to clean up/fix some of its issues.
The problem became even worse when Spotify tried to build a unified UI on top of it (HTML 5 based), with a bridge layer to the C++. The idea was to write once, and (haha) run it everywhere. It failed, for the reasons many of them failed in other companies as well (facebook was doing HTML5 at the time as well).
That got removed, but the problem still remains that "Core" got overly complex as many platforms had their own features, which often were "one off", A/B testing, to see if it works or not. And separate teams (iOS, Android, and Desktop) had their own schedule on this. (It makes perfectly sense to A/B test one feature in Android, and another one in iOS, to see if people even like that feature before making is x-ross platform.
Common platform code, massively slowed down A/B testing of new experimental features, and thus it was a huge cost to the company.
The only solution to this was to keep the common "Core" (as it was called), to the most minimal features needed, and mostly related to playback (ie. song retrieval, caching, retrieval, decryption, playback, and some account features).
Do, the A/B testing on the platform level (iOS, or Android), of it was successful then roll what made sense to the rest (but still trying to keep core as lean as possible).
But since I left few years ago, things might have changed again....
We had some hard requirements on that library because of protocols used by the backend and other reasons. And when you mention features "mostly related to playback", well, it was 95% of the library from its conception (the rest being login and communication with backend). Most of it is quite complex code and not anything you want to rewrite for each platform (mainly offline storage, remote control, playback).
The issues we had were caused by growing pain from having the library initially mixed in the desktop code (back when mobile wasn't a thing). It needed to be extracted, productified and a whole lot of tooling and testing written for it. Once we got there, the quality of the code was much nicer and the integration in the various clients easy and automated (which it couldn't be at first). It certainly took sometime, but it wasn't a problem caused by it being cross platform, only that we needed a better infra. We were there when I left the company about the same time as you for quite a while already.
The integration with various clients got later easier once we removed the need to reach into that library for just fetching simple server side data. But that wasn't a cross-platform library issue, it was mainly a backend issue.
What you described with spotify is that you were essentially building your own phonegap. That might be the right answer if you want to achieve as much code sharing as possible. But just because you can doesn't mean you should. You can't go ahead and make wrong abstractions and assumptions about platforms and then tell me I shouldn't even be trying because you failed at it, when others somehow achieved it. And I know several non-SV companies (a Navigation vendor I worked for for example) that ported their C++ code base to mobile in a matter of days. So it might as well be possible that the engineers in charge at Dropbox, FB etc. were lacking experience.