This paper makes little to no sense.
RGB was designed to be a client-side-validated protocol, what you are instead turning it into is a other-chain-validated protocol, the security of which is then purely dependendent on the security of CKB chain. With that in mind I see no reason to actually even use bitcoin for commiting the transactions, if I need to fully trust CKB I might as well just transact directly on CKB. You are basically using CKB as DA layer for RGB, which is completely uneccessary and redundant.
RGB was made to inherit full security of bitcoin and not depend on any other security assumption, that’s why RGB commits to the off-chain state transitions in a bitcoin transaction, with the off-chain data kept by the transacting parties.
Let me go through the mentioned “Issues with the RGB Protocol”:
DA Isssues - the RGB was especially designed in such a way that there is no DA issue, the transacting parties keep the off-chain data themselves, they are incentivized to store this data because they need it to transact later. There is no need for general data availability and that’s how the system achieves great scalability & privacy.
P2P Network Issues - there really is no need for a P2P network, the off-chain data is sent directly between transacting parties (usually just 2 if we talk about a simple token/NFT transfer), no need to use P2P network for that, you can use tor hidden service, e-mail, whatsapp, telegram, proxy servers to pass the off-chain data to the recipient.
Virtual Machine and Contract Languages - I would agree with this, the question is how much more developed are the development tools on CKB? There really was a lot of thought put into building AluVM & contractum, that stuff really has to be rock solid to be usable in client-side-validated protocol (which of course is no issue for you because you are not a client-side-validated protocol)
Ownerless Contract Issues - yes, this is correct, you cannot have global state in the ethereum sense (AMMs like uniswap, lending pools, etc.), however I would argue that for most things you actually don’t need this and this also scales terribly (AMMs could be replaced by swap providers offering trustless scriptless atomic swaps between tokens, lending pools by lending providers offering a loan for a collateral locked in a DLC output)
In the end you are just shifting the DA and state verification to other blockchain (CKB) - which makes 0 sense, instead of letting it be fully off-chain (gaining all the scalability & privacy gains that RGB has to offer). The end goal of RGB is to kill blockchains and unlock infinite scalability (like in the Prime proposal by LNP/BP association), not adding more blockchains to the mix. You cannot solve issues of blockchains (the fact that everyone has to verify everything) by adding more blockchains.