Most of the time, that is probably the wrong approach for an app to take, but maybe DAWs have latency requirements that can't be met when E cores are in the mix. But that's something the DAW vendors should have to document and justify, because it's just as likely that they're making assumptions about E cores that don't hold up over time across the full range of chips.
The graphs in the source video[0] display 0% utilization on E-cores for some apps.
Given that it only occurs for some DAWs, it's very likely the wrong approach (given that 2/3 of the apps using E-cores have better performance characteristics than the others)
A Better test would be to set up an intensive real world 20 track project, assess utilization and overhead, and then find a real-world way to increment that stress upward to the breaking point.
Most computer music forum wonks use some kind of test based on softsynths or reverbs or a combination and stack them high on a smaller number of tracks.
I mean... 300 tracks? You're basically testing the DAW's thread management at that point, not the CPU as it would be used.
Any realistic test is going to have more tracks than there are CPU cores, so thread management would seem to be an unavoidable aspect of the test. The test results were in the 60–100 track range, not 300, so not really as excessive as you are claiming. And while testing with too many tracks could certainly be problematic for introducing excessive context switching overhead, the problematic behavior that was actually revealed is much more serious and less subtle and applies to any scenario with more than 5–8 threads.
Showing that the efficiency cores aren't fully utilized by the DAWs is appropriate for the audience. It shows to less specialized users that they'll need to examine their tools and their use of efficiency cores to determine if an upgrade is worthwhile