I think there are a few assumptions here that should be cleared up before moving toward a resolution.
- That Polkadot’s goal is simply to be cheaper than Ethereum/Solana/etc.: It’s at least not my goal in working on Polkadot; I want to build a more scalable and performant system with the best architecture and abstractions, and that thus is able to provide a platform on which application developers can give their users the best UX. Ethereum and Solana may be cheap but they are also bloated and one is known for routine shut-downs. When people decide where to deploy something (like collections), of course cost is a factor, but hopefully people have other motivations to choose to deploy on Polkadot.
- That creating collections has no side-effects.: Deposit or not, state is not free. The deposit is there for a reason: more on-chain state results in more expensive weights for everyone because DB reads/writes take longer. So with zero deposit, the issuer is actually pushing the costs into every other user of the chain in the form of higher transaction fees and slower inclusion times. The deposit makes it explicit that there is a cost to storing information on-chain.
As @AshutoshSingh72 pointed out, the existential deposit is 0.1 DOT on Asset Hub to encourage its use over the Relay Chain. This is quite easy to reason about because it’s relative within the system.
But NFT deposits were chosen somewhat arbitrarily at genesis and it’s a good exercise to re-evaluate them and adapt if they are causing pain and if lowering them has little or no negative side effect (or if the trade-off is worth it).
I think this would be perfect for a Fellowship RFC. Any change to the value would require a PR to the Asset Hub runtime under the Fellowship, and although this change would be simple (just a few configuration values), an RFC with discussion on the creator experience, economic constraints, and technical considerations would be valuable and also inform the selection of other deposits in the system.
The procedure is to make an RFC 
.