Mimblewimble (and other variant of non-interactive cut-through) exist, but i don't expect it'll be ever implemented on Bitcoin.
Why not? We currently have full-RBF, which means, that if some transaction is unconfirmed, then it can be replaced completely, without any restrictions. Transaction fee is the only indicator, if something should be replaced, or not. And I expect, that in the future, more people will make use of that, and we will see more and more replacements for unconfirmed transactions, so they will be batched on mempool level.
Because currently, imagine that you have a situation: Alice -> Bob -> Charlie. You have one transaction, which sends some coins from Alice to Bob, and another transaction, which passes them further from Bob into Charlie. If you assume that Alice is online, then there is no reason, to not write a replacement transaction Alice -> Charlie, while using the same fees, and get a higher feerate, because the size of that single transaction, will obviously be smaller, than the size of those two separate transactions, so miners will have no reason to stop that kind of replacement.
And of course, the next natural step, is to make it non-interactive. Because if we have full-RBF, then it means, that interactive version is already there, because full-RBF means "accept any replacement" (including double-spends).
Even though it can be done through soft fork (just like what LTC did)
I don't think Bitcoin will take the same path, as LTC did. It was the case in Segwit, but today, it is much more likely to get some other BIPs merged, for example something related to OP_CAT. And if you have OP_CAT, then it enables a lot of things, including the ability to accept any signature, and do something like OP_CHECKSIGFROMSTACK, but without any additional opcode (other than OP_CAT). And of course, note that doing all of those things, does not require making any "extension block", because you can just use the witness space, as Taproot did.
i wonder if community will accept it since it give government to restrict Bitcoin usage.
If that would be the case, then Bitcoin would be restricted, when it introduced Lightning Network. Because then, you also skip some transactions in the middle, and leave only two on-chain transactions: one to open some channel, and one to close it. Also, another case is Taproot, which allows you to have N people on a single UTXO, by forming N-of-N multisig, behind a single public key, and spending it with a single Schnorr signature.
Improvement for IBD is really limited though
It is not that limited, as you may think. For example: each coin starts from the coinbase transaction, and ends, when it is sent as fees. When it comes to the chain of signatures, it is broken each time, when you send something as a fee, because then the coin is no longer restricted by the Script, so it can be claimed by any miner. Which also means, that if you want to verify things, you don't have to check them deeper, than to the nearest coinbase transaction. Why? Because if the coinbase transaction has 100 confirmations, then it can be spent. And it is very unlikely to ever trigger a deeper chain reorganization, than 100 blocks (even the Value Overflow Incident reorged less than 100 blocks).
There are many bugs, where if something went wrong, then the historical state of the chain, was simply "grandfathered in", and new rules were applied on top of the later chain. One of those cases is for example duplicate coinbase transactions: nobody proposed throwing away the history to fix it (because it was deeply confirmed), and some coinbase transactions are just listed in the code as "exceptions" to some BIP, so they are ignored, while checking, if there are no duplicated transaction IDs.
unless you skip more verification
You don't have to skip it, if you don't want to. It can be fully optional, because if you replace Alice -> Bob -> Charlie transaction with just Alice -> Charlie, then it will probably contain Alice's signature. And inside that signature, you can put a proof, that there was Bob in-between, so some nodes can still access that history, and preserve it, if there would be any need to show someone, that "Bob owned some coins at this point in time". However, at the same time, it would no longer be strictly needed, if you want to synchronize the chain from scratch, because Alice's signature is correct from ECDSA point of view, and nothing else is needed to prove, that no coins were created out of thin air, and the system is honest.