I believe rclone had flattening early on - but it was removed. I think it had something to do with limitations of certain cloud backends making that approach incompatible. You would have to get an answer from @ncw for the details I think (and I would be interested to know too).
It would be nice if we could have it as an optional feature for those backends that can support it - but it may be that this would break a lot of other code and require a lot of functions to basically be maintained twice to support both. I don't know.. maybe NCW can elaborate as it's a fascinating topic and I wasn't around back when I heard this was still a thing.
Encrypted files are allready not the same exact size as the original. They are slightly longer, and I don't think you can trivially calculate what the real size is without having the crypt-key. But of course they are very obviously "about" the same length... that info is pretty hard to mis-use though when it's not exact.
For large files you know about chunker...
But I absolutely agree that a "merger" would be really nice for small files (and I have some ideas on how to implement it I will pitch to NCW). I am personally more interested in the performance potential of it than the security benefit - as many/most cloud backends struggle in performance on many tiny files. Transferring them as one larger unit would be very beneficial in a lot of cases.
I gave you the link to the issues page in the other thread if you want to formalize any of these ideas and add more detail to them. And should you know how to program than by all means - make a pull request and have a go at it. The code is open to contributions and NCW will assist where needed. He is always very keen on help as he has a ton on his to-do list already for this project.