There's nested sandboxes for browsers in mobile environments. There's the inner layer which the web content is running in, but then the browser itself is sandboxed so it can't do things like access OS APIs it doesn't have permission for, install apps that run in the background, etc. This is why the iOS example needed 3 exploits chained. The fact that a similar example worked on Android, which also has app sandboxing, implies there should be an exploit chain but we've only been told of the first.
But browsers, especially Chrome, have lots of permissions (including geolocation, accessing SD card, accessing user's personal data, camera and microphone etc.). You don't need to do anything if you can run under browser's privileges.
You still want priv escalation if you're trying to spy on someone. The content process can't see anything you're doing in other apps, and the browser can only access a very restricted view of the storage
Living in memory or living off the land is generally a good idea, but you still want a chain of exploits anyways
Persistence means you can write to something that'll cause your malware to run again after reboot, but external storage isn't enough to do that without another exploit in the boot path, right?
Android has clamped down hard on access to the SD card. Chrome certainly doesn't have the special All Files Access, and on my device it doesn't even have Photos or Music, since I never use those permissions with Chrome, and Android regularly turns off permissions that haven't been used recently
