There are several problems with this proposal, but let's start with the most practical ones.

First, how will anyone know who to pay? Every node would somehow need to announce what Bitcoin address they should be paid at, and there would need to be a way to verify that the address is associated with a legitimate and separate node, not just someone announcing an address into the network without actually running a node. This is not an issue with mining rewards because the proof is in the data itself. They found a valid hash, so they get paid, and they put in the block that they created exactly how they get paid. Nodes don't do any PoW, though, so there is no way to verify whether an announced address really belongs to a node operator, or just some dude who wants some easy passive sats.

What happens when new nodes come on the network? They will need to store all the same data as existing nodes, so shouldn't they be paid by those who put that data on the network, too? Or should they only be paid for data that is added after they joined? If the latter is the case, then they are storing a lot of previous data that they aren't compensated for, but others were. What is their incentive to store that data?

The economics here is ridiculous. There are currently somewhere between 45,000–50,000 Bitcoin nodes. That number is not exact because it can't be. We don't know how many are running behind Tor or in other private networks, so the best we can do is estimate. Refer back to the first main issue with your proposal above. But let's just spitball some numbers here. If the proposal was something like 1 sat per KB per node, then a 1 KB piece of arbitrary data would cost 45k-50k sats with the current node count, plus the transaction fees for sending each of those transactions. Assuming this would be done using 1 input and 45,000 outputs on the low end, and best possible case scenario of 1 sat/vbyte transaction fee, the cost would be somewhere around 1,400,000 sats for the transaction fee alone, even with the lower estimate on how many nodes there are on the network. And node count would almost certainly go up, since this would be a direct financial incentive to run a node.

Things get more ridiculous from there, because 1 sat UTXOs are dust and unspendable. For a UTXO to be spendable, even in a low fee environment, it needs to exceed 546 sats, and practically, it needs to be more than 20k sats to be worth moving on-chain. And you HAVE to do this on-chain, because there is no way for Bitcoin to verify anything that takes place off-chain. If the node runners are paid via lightning, for instance, how will miners who select the transactions they put into a block know whether a particular transaction with arbitrary data included has paid the nodes to store that data or not? This means that even in the best-case scenario, each node must be paid a minimum of 546 sats for it to be above the dust limit, raising the cost to put arbitrary data on chain to a minimum of 24,570,000 sats for the 45,000 node runners to each get 546 sats, plus 1,400,000 in transaction fees, plus the transaction fee for the amount of data they are including in the transaction...

The final practical issue I will address is the fact that there is no way to prevent miners from including transactions that don't pay nodes a single sat. This is part of the basic game-theory that Bitcoin is built on. Miners select what transactions they will include in a block based on their own priorities, and since there are enough miners with different priorities, most transactions will eventually find their way into a block. Most miners operate on economic incentives, selecting the transactions that will result in them receiving the most fee income, but not always. If someone who really wants to put data onto the blockchain includes a high enough fee to the miners, without any payment to nodes whatsoever, some miner WILL pick up that transaction and include it in a block. The nodes could reject that block, but this would require a concrete consensus rule as the basis for doing so. A node couldn't just reject it because it contained a transaction with arbitrary data that did not also include a payment to the node's Bitcoin address to store that data. This would result in the nodes falling out of consensus with one another whenever there was a transaction that didn't pay absolutely every node on the network. But it couldn't be as simple as rejecting any block containing a transaction with arbitrary data that didn't pay any nodes, either. Otherwise the system could be too easily gamed, paying only one node, but all nodes then need to store the transaction forever. So it would need to be set to some standard of at least 90% of nodes. This would require each node to store a database of nodes and their Bitcoin addresses, so they could verify that the correct threshold had been paid, and this would become a new attack vector for breaking Bitcoin's consensus.

So, with all of the above practical issues, plus almost certainly a host of technical issues that would be above my head, and the social issue that such a change would be incredibly controversial, I think I can confidently say this idea is dead in the water.