Why confidential TXs are not implemented in Bitcoin?
Because it requires a soft-fork. In general, things that require soft-fork, are not things you can easily introduce. You have to go through the same path as in Segwit or Taproot, it is a long process of reaching consensus, and people can always reject your proposal, then you have to try some no-fork, which is harder.
You can also ask the same question about other features, like sidechains, and you will get a similar answer. Also, as things like confidential transactions can enable sidechains as a side-effect, people will carefully check that they won't. The same is true for any transaction joining features, that could enable sidechains.
Recently, it turned out that Taproot can be used for NFTs, and it is side-effect that was never planned. For that reason, any feature that could have undesired side-effects, will take a long time to introduce. And confidential transactions is one of those features.
how do we know the fee?
Even in Monero, you know the amount in the coinbase transaction. Fee has to be explicit, because if it won't be, then non-upgraded nodes cannot see the coinbase amount. So, all amounts are hidden, but fees are explicitly visible, and the whole computation is done only for those hidden amounts.
that changes the TX format where UTXOs are encrypted
Changing the transaction format is a big change. Even in typical soft-forks, when you have Segwit vs non-Segwit addresses, all old nodes can understand Segwit transactions to some extent. They cannot see the witness, but they can see many other things, and perform at least partial validation.
Also, I guess that if something like that will ever be introduced, then it will be a part of Taproot or something around that. So, if you want to hide addresses, then a single old-style output will represent many new-style outputs, so old nodes will know that coins were moved, but they will have no idea, how to process the proof (similar to witness vs non-witness nodes). However, when it comes to amounts, they have to be accumulated.
The basic building block for Taproot is N-of-N multisig with Schnorr signatures, through spending by key. So, that could be your H, then if everyone agrees, it can be simplified to a single signature. And then, maybe it is a matter of redefining some OP_SUCCESS, or changing Taproot sighashes. Because now, you can create a confidential transaction, where people will see that 1 BTC from some Taproot address moved, but nobody will know, how many users were there, and how this amount was internally splitted between them. So, that proposal will just make it non-interactive, where you could take 0.5 BTC out of that, and send to another Taproot address, and again, nobody will know if a single person moved 0.5 BTC, or maybe two people moved 0.2 BTC and 0.3 BTC, so you will reach that confidentiality. Also, if it would be non-interactive, then all confidential transactions could be batched in a huge UTXO, then you will know that 1000 BTC moved, but you won't know how many users were there, and which amount they used, because it will be batched before going on-chain.
I don't understand this part about inflation, would be grateful if u can explain it if u understand it
If amounts are hidden, then you don't know, which value is behind. And then, some tricks are possible, similar to Value Overflow Incident, but using a different modulo, inside ECDSA. It is basically about hacking the proof that protects from overflow. Because that proof only works in certain conditions, and it is still unlikely, but mathematically possible, to produce something that will pass the verification, but will act as a negative value, and will allow producing more coins.
It is similar to other things, like SHA-256: if it works as intended, then ECDSA works. But break SHA-256, and then you can sign any coins, because from any public key, you can make a valid signature for random z-value, and then if you can break SHA-256, then you can make it valid. Here, it is similar: if you can break some assumptions, then you can produce a value, that will overflow, but will pass overflow protections. One of those things is finding a private key for H.
