but for how long are we going to continue like this ?.
As long, as needed, to reach transaction joining, and improve batching.
Even with this implementation, we haven't been able to say "Goodbye" to congestion.
Because those tools are not there, to get rid of congestion for legacy transactions. They are there, to allow cheaper transactions for those, who opt-in. Everyone else will pay for that, as usual, because those changes are backward-compatible.
but this idea wasn't enough to get approval from the community due to the absence of replay protection.
1. It was because of hard-fork, not because of replay protection.
2. If you want to introduce replay protection, it can be done at the level of the coinbase transaction, but BTC simply didn't introduce replay protection as a soft-fork, and altcoins like BCH didn't bother to make it "gradually activated", or to maintain any compatibility in sighashes. Imagine how better some altcoins could be, if all of their transactions would be compatible with BTC, and if everything, what was confirmed on BCH, would be eventually confirmed on BTC, and vice versa. Then, you would have 1:1 peg, and avoid a lot of issues.
Meaning, the absence of this protection could cause a replay attack.
It is a feature, not a bug. For example, some people told about things like "flippening", where some altcoin would reach bigger hashrate than BTC, and take the lead. But: those altcoin creators introduced incompatible changes, which effectively destroyed any chance for such "flippening". Because guess what: it is possible to start from two different points, then reach identical UTXO set on both chains, and then simply switch into the heaviest chain, without affecting any user. But many people wanted to split coins, not to merge them. And if splitting and dumping coins is profitable, then the end result can be easily predicted.
This was suppose to address the issue, but it doesn't have a say in the size of blocks either.
If you want to solve the problem of scalability, then the perfect solution is when you don't have to care about things like the maximum size of the block. Then, it "scales": if you can do 2x more transactions, without touching the maximum block size, then it is "scalable". If you can do 2x more transactions, and it consumes 2x more resources, then it is not "scaling" anymore. It is just "linear growth". And it can be done without any changes in the code, just release N altcoins: BTC1, BTC2, BTC3, ..., BTCN, and tada! You have N times more space!
but what's now left for others like myself rather than to sit and wait on the queue along other transactions that are available on the mempool ?.
If you need some technical solution, then you need a better code. Then, you have two options: write a better code, or find someone, who will do that.
What do you think is a possible solution to this problem?.
Transaction joining, batching, and having more than one person on a single UTXO in a decentralized way.