That wouldn't be good if they're targeting battery-powered devices, because you usually don't want to turn on extra cores there. Mobile programs can actually go faster if you make them single-threaded - either the device doesn't have more cores available to run your extra threads, or your process isn't high-priority enough to spend more power on.

Isn’t the point of high core counts for workloads that can actually be parallelized? Like compilation or graphics rendering?

A lot of tasks can be parallelized if you think hard enough. Your CPU is busy reordering instructions so they keep as many execution ports busy as it can so that it can retire as many instructions per core cycle as possible. SMT was invented to keep those execution units busy by running more than one instruction stream at a time.

The incentive to do it when most computers have two SMT2 cores is small, but as the average device starts getting 4 or 8 SMT2 cores, or 8 asymmetric cores, the incentives to make things run faster in parallel get better and better.

A lot more things can be parallelised than we do today.

Consider this: We mostly parallelize compilation today at the unit of a single compilation unit.

We do this for two reasons: It's simple, for languages where separate compilation is possible, and it's good enough when you have a small-ish (smaller than the number of compilation units) number of fast cores.

But a lot of compilation can be reduced into far more fine-grained parallel steps.

E.g. parsing can be turned into a chain of array operations along the line of finding possible start/ends of tokens, finding possible starts and ends of quoted segments, finding possible starting points for matches against various rules based on the possible token starts etc. You can further build syntax trees as arrays of vectors. If you have many enough cores it may pay off to subdivide the work to extreme levels like that.

But it's hard to reason about. We're not used to it, and most of us are no good at conceptualising it. Some are.

For a real-life example of a compiler that actually runs on GPU's and aims for massive parallelisation (it compiles a subset of Dyalog APL), check out "co-dfn" by Aaron Hsu. It's very terse and complex to read, and frankly I've only spent time looking at it very superficially, but it's an amazing piece of work. Now, if it was easier for mere mortals to actually write code like that, and we had a more compelling reason (many, but slower cores), we'd probably see a lot more parallelisation. In the short run it'd be extremely painful, but in the long run it might well benefit us.