I suspect that long term big.little is not going to be all that important. It is more of a stepping stone along the way.
My logic goes something like "why have 4 small cores and 4 big cores when you could have 8 big cores". Then the argument goes "yes but the small cores use less power", to which my replay is "true, but the big cores finish faster and can spend more time sleeping, I think the power argument evens out ether way".
The real gain is to have better power management for the cores, not by having weird small cores.
There are some wrinkles to this: First, big cores are less efficient per unit work because there's a lot of complexity in things like reordering, speculation, and pipelining and that complexity costs energy. A design optimized for peak throughput per time looks different than a design optimized for peak throughput per energy. Second, reducing area and energy for the cores allows spending those resources somewhere else like larger caches which, to a point, can reduce energy further. Third, realtime workloads can't really be delayed without compromising user experience so you're going to be waking some cores up constantly anyway. Might as well have a few efficiency-optimized cores and pile as much on them as possible to keep latency and energy consumption low.
Not all tasks can finish fast. They're just constant low level jobs waiting on IO most of the time. Operating systems are full of suck tasks. It's better to let them run on the LITTLE cores since integrated over time they'll use less power than the big cores.
My logic goes something like "why have 4 small cores and 4 big cores when you could have 8 big cores". Then the argument goes "yes but the small cores use less power", to which my replay is "true, but the big cores finish faster and can spend more time sleeping, I think the power argument evens out ether way". The real gain is to have better power management for the cores, not by having weird small cores.