These benefits are not without their own downsides. Your application will be competing with all other applications for the limited shared time on the single threaded virtual CPU.

Not necessarily. You can have multiple sidechains moving in lockstep with one another acting as a single blockchain. Each side chain has its own isolated database state. Validated messages can be sent from one sidechain to the other at block boundaries only. Within a given block in a sidechain, all transaction operations are applied sequentially. But all the sidechains working on their own block would do this in parallel. The block producers of the main blockchain must run the smart contracts on all sidechains and compute their results if they want to be able to produce the next set of blocks. And that constraint allows this design to provide greater security compared to multisig-based sidechains. But you still have scaling because the computation for each sidechain can occur in a separate process running on different servers.

So as an example, you can have a DEX DApp that separates the DApp into many sub-DApps that each run a specific market. Then the market orders run sequentially (which is inherent to the nature of matching orders at best price) for a particular market, but in parallel with the order matching happening in all other markets of the DEX DApp. Inter-sidechain communication could allow a user to move their funds from one market to another.

Of course this sidechain design does mean that the DApp developers have to decide which sidechain their DApp will exist within. And their code needs to be written to take into account the fact that intra-sidechain communication between smart contracts or DApps is very different from inter-sidechain communication: there is added latency (because inter-sidechain communication only happens at block boundaries), and more importantly you cannot have a program that executes inter-sidechain communication within to run as part of a single atomic transaction.

So going back to the DEX DApp example, the limitations mean that if you have two markets each on their own sidechain, a user could not submit an atomic transaction that sells asset A for asset B (in the A/B market in one sidechain) and then sells the received asset B for asset C (in the B/C market in another sidechain) and only is carried out if it is possible to fully convert A to C. Instead, they would be forced to break it up into two transactions which means that they may get stuck with an asset B (depending on changing market conditions) that they did not wish to hold. Doing that atomically, however, is something that a DApp on the less-scalable design of the fully programmable platform (like Ethereum's current design) could be built to do. Of course, a DApp dev need not choose either extreme. They can go with the more scalable design I described above but choose which parts of their DApp should belong on the same sidechain (to get the atomicity benefits at the cost of less scalability) and which parts should be on different sidechains (but that still can benefit from synergy through secure inter-sidechain communication).