advantages of concurrency and the ecosystem strategy
There's parallelism in the world - things that are spatially separated, a tiny bit as in a vector of bits that is processed in parallel in your graphics processor, or a bit larger as in the several "cores" (essentially, CPUs) which are likely in your CPU, or much larger as in the server serving this web page and your client. Taking advantage of that parallelism is necessary and important and difficult, but not my focus at the moment.
Concurrency is a difficulty of some domains, something like stochastic dynamics or partial observability. Not all domains have stochastic dynamics, partial observability, or concurrency, but enough do that we care about techniques to deal with it. If you have to juggle multiple concerns - e.g. keeping several distinct disks spinning, or converse with multiple clients at the same time, then you have concurrency.
Even if you currently have a serial semantics (e.g. If you're writing Javascript in the browser, then you currently have serial semantics - even if the CPU has multiple cores. If you wrote a multicore virtual machine in Javascript, then when you're writing code intended to run on that virtual machine you would have parallel semantics.
I think there's an analogy to be made between choosing to introduce concurrency, writing or adopting a "green" threading system or similar, and the ecosystem strategy. A nation, even if it is a stable dictatorship, might well choose to create a market, to allow some autonomy and self-interest to these sub-organizations simply because the computational costs of micromanaging all of the things that have to be done are too great. Microsoft and Apple and Valve are all examples of big wins for the ecosystem strategy. The outer, nation-ish corporation provides services, either free or cheap, to dependent corporations, and exacts from the dependents something like a tax. The customers enjoy these walled gardens, which are more rich and various than anything that a single team with a single vision could create, however talented.
When you're designing an application that has a richly textured domain (which is most medium-sized-and-larger applications, though some high-prestige domains are very spartan - e.g. compilers and high-performance scientific computing and some kinds of AI.), the quantity of details that you need to deal with is overwhelming. In order to deal with those, people divide the domain up and then use perspectival abstraction. Perspectival abstraction is something like the famous "view from 9th avenue", where things further away are abstracted more. When working on one piece of the puzzle, you (empathetically) identify with that piece's perspective on the whole.
Another example of a perspectival representation is a road sign indicating direction and perhaps distance to various notable points; local destinations are allocated the same amount of space on the sign as much more notable destinations that are further away. Note that, as a whole, the various perspectives add up to a holographic self-representation - a road network with a perspectival road sign at every intersection is holographically self-representing road network. The internet with routers and routes
This perspectival decomposition is the key insight of object orientation for me - inheritance is a snare, and polymorphism is fine but it's not always important and it's not unusual to have polymorphism in other so-called "paradigms" of programming; the fact that OO advocates usually focus on polymorphism isn't actually because OO does polymorphism much better, it's that OO doesn't have much else to boast about. Perspectival decomposition is not always necessary (as I mentioned, some domains are quite spartan), but it's difficult to illustrate domains where it's necessary because their characteristic is their size and richness of detail. (This is an example of a self-keeping secret - there really are magical secrets that cause your tongue to get heavy and your voice to get hoarse when you try to speak them directly - large, richly detailed domains could take months to learn or teach.)
Concurrency is a difficulty of some domains, something like stochastic dynamics or partial observability. Not all domains have stochastic dynamics, partial observability, or concurrency, but enough do that we care about techniques to deal with it. If you have to juggle multiple concerns - e.g. keeping several distinct disks spinning, or converse with multiple clients at the same time, then you have concurrency.
Even if you currently have a serial semantics (e.g. If you're writing Javascript in the browser, then you currently have serial semantics - even if the CPU has multiple cores. If you wrote a multicore virtual machine in Javascript, then when you're writing code intended to run on that virtual machine you would have parallel semantics.
I think there's an analogy to be made between choosing to introduce concurrency, writing or adopting a "green" threading system or similar, and the ecosystem strategy. A nation, even if it is a stable dictatorship, might well choose to create a market, to allow some autonomy and self-interest to these sub-organizations simply because the computational costs of micromanaging all of the things that have to be done are too great. Microsoft and Apple and Valve are all examples of big wins for the ecosystem strategy. The outer, nation-ish corporation provides services, either free or cheap, to dependent corporations, and exacts from the dependents something like a tax. The customers enjoy these walled gardens, which are more rich and various than anything that a single team with a single vision could create, however talented.
When you're designing an application that has a richly textured domain (which is most medium-sized-and-larger applications, though some high-prestige domains are very spartan - e.g. compilers and high-performance scientific computing and some kinds of AI.), the quantity of details that you need to deal with is overwhelming. In order to deal with those, people divide the domain up and then use perspectival abstraction. Perspectival abstraction is something like the famous "view from 9th avenue", where things further away are abstracted more. When working on one piece of the puzzle, you (empathetically) identify with that piece's perspective on the whole.
Another example of a perspectival representation is a road sign indicating direction and perhaps distance to various notable points; local destinations are allocated the same amount of space on the sign as much more notable destinations that are further away. Note that, as a whole, the various perspectives add up to a holographic self-representation - a road network with a perspectival road sign at every intersection is holographically self-representing road network. The internet with routers and routes
This perspectival decomposition is the key insight of object orientation for me - inheritance is a snare, and polymorphism is fine but it's not always important and it's not unusual to have polymorphism in other so-called "paradigms" of programming; the fact that OO advocates usually focus on polymorphism isn't actually because OO does polymorphism much better, it's that OO doesn't have much else to boast about. Perspectival decomposition is not always necessary (as I mentioned, some domains are quite spartan), but it's difficult to illustrate domains where it's necessary because their characteristic is their size and richness of detail. (This is an example of a self-keeping secret - there really are magical secrets that cause your tongue to get heavy and your voice to get hoarse when you try to speak them directly - large, richly detailed domains could take months to learn or teach.)