Yes, this would be very useful. The benefits of archiving together tons of small files is obvious just from doing it manually. 5M files aren't the ones that hurt the most, but when you go even smaller (which a surprising amount of files are) then it really kills performance badly.
A backend that could merge small files into a larger one would be great and I've had my mind on this idea for a long time. Ideally this would allow rclone to present the files "normally" and doing this job transparently for you.
Archiving the files would be a means to do this, and compression is often a good idea on small files as they tend be quite compressible, but technically it wouldn't be required I think - so maybe these tasks should be kept separate functions? As long as rclone knew where the individual files start in the large amalgamation you could just glue the bits together into a long file. Seeking is apparently quite fast - it's opening and closing files that takes a long time and has pretty hard restrictions on many services. So it should be relatively quick to pull out a handful of files you need from a big package.
I think the largest obstacle to this is how to handle the metadata needed smartly. Where files start and stop has to be saved somewhere, preferably on the remote itself. Do you use an index file pr "package", or some sort of centralized database file? In the niggty gritty details there are a lot of pros and cons you have to weigh out there. But is it possible? Almost certainly.
There is a "press remote" backend in the works currently that tackles the compression issue on it's own, but it does not currently deal with combining files (which is the even more important issue here I think). it would perhaps be a natural thing to extend this functionality to though.
If you have coding experience (rclone uses go, similar to C# and java) then be aware that anyone can help contribute to rclone's codebase. NCW will no doubt help you along as needed. He is always very enthusiastic about assistance
@ncw This seems relevant for you I think, for future feature plans and such