user780: Why does the Plutus script need be provided in the transaction?
My understanding is that a script address is just a hash of the script. In order to spend a UTxO from a script address the spending transaction needs to include the script. The validator will check if the attached script's hash matches the script address and then execute the script to check if the input is allowed to be spent.
So the script needs to be known to whoever wants to spend a UTxo from a script address. The actual script can be attached to the UTxO when it is created on the script address so you can know what script needs to be used to unlock the funds. However, you still need to provide the script in the spending transaction.
This means that any time a UTxO from a smart contract address is spent, the transaction needs to include the script. If the script was stored separately on the address, then a spending transaction would only need to point to that script instead of spamming the blockchain with duplicate data. What am I missing here?

user2537: Having the script not attached to the UTxO outputs but to the spending transaction reduces the memory consumption of the nodes because UTxOs are stored in memory. Transactions can be pushed to the storage and erased from the cache once the transaction is confirmed and the slot added to the blockchain. Also (though I don't know if Cardano does this optimisation) you could reduce transaction sizes by having each script attached only once to the transaction when multiple UTxOs of the transaction need the same script.

user1897: An update on one part of the question that hasn't been addressable till now

If the script was stored separately on the address, then a spending
transaction would only need to point to that script instead of
spamming the blockchain with duplicate data. What am I missing here?

Well, this is exactly what a new Cardano Improvement Proposals called CIP-33 (Reference scripts) seems to be rooting for.
From the CIP-33 proposal

We propose to allow scripts ("reference scripts") to be attached to
outputs, and to allow reference scripts to be used to satisfy script
requirements during validation, rather than requiring the spending
transaction to do so. This will allow transactions using common
scripts to be much smaller.

at the end it summarizes as below:

The key idea of this proposal is stop sending frequently-used scripts
to the chain every time they are used, but rather make them available
in a persistent way on-chain.

So fingers crossed, if this makes it into some future release, we will have enormous reduction in size of transactions and a lot more transactions would fit in into a block.
UPDATE: The Vasil hard fork is happening on mainnet on 22 Sep 2022 (already available on testnet)
Other CIPs of interest :

CIP32 - Inline Datums
CIP31 - Reference Inputs


780: <p>Why does the Plutus script need be provided in the transaction?</p>
<p>My understanding is that a script address is just a hash of the script. In order to spend a UTxO from a script address the spending transaction needs to include the script. The validator will check if the attached script's hash matches the script address and then execute the script to check if the input is allowed to be spent.</p>
<p>So the script needs to be known to whoever wants to spend a UTxo from a script address. The actual script can be attached to the UTxO when it is created on the script address so you can know what script needs to be used to unlock the funds. However, you still need to provide the script in the spending transaction.</p>
<p>This means that any time a UTxO from a smart contract address is spent, the transaction needs to include the script. If the script was stored separately on the address, then a spending transaction would only need to <em>point</em> to that script instead of spamming the blockchain with duplicate data. What am I missing here?</p>
 2537: <p>Having the script not attached to the UTxO outputs but to the spending transaction reduces the memory consumption of the nodes because UTxOs are stored in memory. Transactions can be pushed to the storage and erased from the cache once the transaction is confirmed and the slot added to the blockchain. Also (though I don't know if Cardano does this optimisation) you could reduce transaction sizes by having each script attached only once to the transaction when multiple UTxOs of the transaction need the same script.</p>
 1897: <p>An update on one part of the question that hasn't been addressable till now</p>
<blockquote>
<p>If the script was stored separately on the address, then a spending
transaction would only need to point to that script instead of
spamming the blockchain with duplicate data. What am I missing here?</p>
</blockquote>
<p>Well, this is exactly what a new Cardano Improvement Proposals called CIP-33 (Reference scripts) seems to be rooting for.</p>
<p>From the <a href="https://cips.cardano.org/cips/cip33" rel="nofollow noreferrer">CIP-33 proposal</a></p>
<blockquote>
<p>We propose to allow scripts (&quot;reference scripts&quot;) to be attached to
outputs, and to allow reference scripts to be used to satisfy script
requirements during validation, rather than requiring the spending
transaction to do so. This will allow transactions using common
scripts to be much smaller.</p>
</blockquote>
<p>at the end it summarizes as below:</p>
<blockquote>
<p>The key idea of this proposal is stop sending frequently-used scripts
to the chain every time they are used, but rather make them available
in a persistent way on-chain.</p>
</blockquote>
<p>So fingers crossed, if this makes it into some future release, we will have enormous reduction in size of transactions and a lot more transactions would fit in into a block.</p>
<p>UPDATE: The Vasil hard fork is happening on mainnet on 22 Sep 2022 (already available on testnet)</p>
<p>Other CIPs of interest :</p>
<ol>
<li><a href="https://github.com/cardano-foundation/CIPs/pull/160" rel="nofollow noreferrer">CIP32 - Inline Datums</a></li>
<li><a href="https://github.com/cardano-foundation/CIPs/pull/159" rel="nofollow noreferrer">CIP31 - Reference Inputs</a></li>
</ol>
