user5261: There is this beautiful eUTXO handbook which state scalability as one of the main advantage of the eUTXO accounting model.
How and why is that essentially?

user1142: The scalability of the eUTxO model is simply the ability to include multiple transactions in one transaction.
For example: A company wants to send salaries to all its employees. Instead of creating 1 transaction for each employee, they can craft 1 transaction that contains 1 or many input UTxOs and many output UTxOs that are sent to the wallets of the employees.
These transactions can also contain smart contracts in addition to simple transactions and are only limited by the maximum size of one transaction.
A beautiful visualization of this can be found here: https://eutxo.org/

user2335: Besides what @Eddex stated, there is a more fundamental reason why an UTxO model scales better than an account model base blockchain.
TLDR: A UTxO model is more concurrent due to the atomic nature of unspent outputs.
In a UTxO model, state (that which describes a system) is localized in the form of an unspent output. Propagation of such a state is the consumption of it. Here, the collective/global state of the chain is described by all the outputs together. In the account model, state is always global. There is no subdivision of smaller units like UTxO's.
Why are smaller units important for scalability? Given that each block a set of transactions mutate the state, we could have that smaller sections of the state and their propagation do not intersect. Since these transactions do not intersect, you know for sure that they do not influence each other. This means that the validation of such a collection of non-intersecting transactions can be validated separately, or more specific, concurrently. This allows for protocols like Hydra more naturally, this is a protocol for off chain handling of an isolated set of outputs between parties. Since these are isolated, multiple Hydra heads can concurrently propagate the set of outputs.
Now of course an account model can also create state channels, but the problem there is that they have global state! This means that for an account model, we first have to decide how to cut up the global state onchain to concurrently validate its propagation (how do you decide such a thing? It's not a trivial task if it's an interconnected web of codependent state).
Now with all good comes some bad, by starting with local state (the utxo model) Cardano gains scalability, but has trouble creating global state. We saw that with the testnet launch of the initial Minswap dex. It just means that the protocol designs on Cardano are harder when global state is involved.
By starting with global state, you gain easy and straightforward coding of protocols, but lack scalability. This is why Ethereum is so focused on sharding (the process of cutting up their global state into smaller pieces) for their scaling plan, though again, this is no trivial task.

5261: <p>There is this beautiful <a href="https://ucarecdn.com/3da33f2f-73ac-4c9b-844b-f215dcce0628/EUTXOhandbook_for_EC.pdf" rel="nofollow noreferrer">eUTXO handbook</a> which state scalability as one of the main advantage of the eUTXO accounting model.</p>
<p>How and why is that essentially?</p>
 1142: <p>The scalability of the eUTxO model is simply the ability to include multiple transactions in one transaction.</p>
<p>For example: A company wants to send salaries to all its employees. Instead of creating 1 transaction for each employee, they can craft 1 transaction that contains 1 or many input UTxOs and many output UTxOs that are sent to the wallets of the employees.</p>
<p>These transactions can also contain smart contracts in addition to simple transactions and are only limited by the maximum size of one transaction.</p>
<p>A beautiful visualization of this can be found here: <a href="https://eutxo.org/" rel="nofollow noreferrer">https://eutxo.org/</a></p>
 2335: <p>Besides what @Eddex stated, there is a more fundamental reason why an UTxO model scales better than an account model base blockchain.</p>
<p><strong>TLDR:</strong> A UTxO model is more concurrent due to the atomic nature of unspent outputs.</p>
<p>In a UTxO model, state (that which describes a system) is localized in the form of an unspent output. Propagation of such a state is the consumption of it. Here, the collective/global state of the chain is described by all the outputs together. In the account model, state is always global. There is no subdivision of smaller units like UTxO's.</p>
<p>Why are smaller units important for scalability? Given that each block a set of transactions mutate the state, we could have that smaller sections of the state and their propagation do not intersect. Since these transactions do not intersect, you know for sure that they do not influence each other. This means that the validation of such a collection of non-intersecting transactions can be validated <strong>separately</strong>, or more specific, concurrently. This allows for protocols like Hydra more naturally, this is a protocol for off chain handling of an isolated set of outputs between parties. Since these are isolated, multiple Hydra heads can concurrently propagate the set of outputs.</p>
<p>Now of course an account model can also create state channels, but the problem there is that they have global state! This means that for an account model, we first have to decide how to cut up the global state onchain to concurrently validate its propagation (how do you decide such a thing? It's not a trivial task if it's an interconnected web of codependent state).</p>
<p>Now with all good comes some bad, by starting with local state (the utxo model) Cardano gains scalability, but has trouble creating global state. We saw that with the testnet launch of the initial Minswap dex. It just means that the protocol designs on Cardano are harder when global state is involved.</p>
<p>By starting with global state, you gain easy and straightforward coding of protocols, but lack scalability. This is why Ethereum is so focused on <a href="https://www.digitalocean.com/community/tutorials/understanding-database-sharding" rel="nofollow noreferrer">sharding</a> (the process of cutting up their global state into smaller pieces) for their scaling plan, though again, this is no trivial task.</p>
