You running knots versus core does nothing for how much data is stored by your blockchain. Knots accepts all the same blocks on the chain as core.
BIP-110 also doesn't change anything with regards to the potential storage requirements of running a node since the amount of data stored for any given block remains the same.
At the end of the day, BIP-110 was selling a lie.
Data storage for bitcoin's blockchain remains a linear non-issue. Every block has a max size which means the blockchain grows linearly and therefore storage requirements over time for a pleb node runner is overcome easily with cheap consumer hardware.
If anything, not using OP_RETURN for arbitrary data is what increases node requirements since if that data is otherwise stored in the UTXO set, it WILL increase your node requirements since the UTXO set is stored in RAM, which is also far more costly.
Also, if the ColdCard debacle taught us anything about a proper SDLC, it is that you need robust commit tracking for code changes and the way that Luke maintains Knots mirrors the way that ColdCard maintained its firmware, if not worse. There is no code signing of the changes that Luke is committing to Knots from their source. You lose tracking of what the code changes actually are. It is a pet project of Luke's and I'd caution anyone serious about security to avoid running it.
