I don't quite understand why AES CBC was removed in TLS1.3.
From what I know CBC is the most secure Mode of operation for the AES block cipher (if you can say it like that).
It only needs a TRND IV and has not been broken. If you pair it with a decent HMAC I guess It's at least as secure and AES-GCM.
So why is AES-GCM preferred and the CBC support was removed?
Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.
AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.
In particular, within the history of the SSL and TLS protocols, there is a long history of security vulnerabilities resulting from misuse of CBC mode or within combination of CBC and MAC, such as BEAST and Lucky13.
After the Lucky13 attack (a timing oracle caused by MAC-then-encrypt), it was thought that TLS should change ordering of the operations. Changing order of the operations would have affected the backwards compatibility with previous implementations so it was after all thought that it is more practical to switch to authenticated encryption only.
In addition to security aspects, there are some other practical benefits of AES-GCM over AES-CBC and HMAC:
TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility.
Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS vulnerable to CBC padding oracle attacks. As you've already noted, it requires an IV that cannot be predicted by an attacker and the cipher fails if this requirement isn't met.
These kind of attacks are easily avoided by AEAD (authenticated) ciphers such as GCM. These modes come with security proofs (build on top of a secure block cipher / MAC algorithm). This makes them less likely to be vulnerable to the previous attacks on CBC mode. As they tend to be more efficient as well there it is simply no reason to avoid an already specified AEAD cipher such as GCM. GCM is build on top of CTR mode, so the cipher doesn't require padding, removing one of the possible attack vectors.
There has actually been a try to make CBC then HMAC an official AEAD cipher in this RFC proposal. This AEAD cipher never made it past the draft stage however. It would still require the special IV and it would be less efficient; there is no reason to include it if your goal is maximum efficiency and security for TLS 1.3.
from what I know CBC is the most secure Mode of operation for the AES block cipher
I'm not exactly sure why you say this; however, there has been a couple of practical problems with CBC mode in the past:
Padding Oracle attacks; as originally designed in SSL (and carried into TLS 1.2), the way TLS implements CBC mode (with the padding and the HMAC) is prone to various decryption oracle attacks (where the attacker modifies the TLS record, and watches how the decryptor reacts). It is possible to design a TLS decryptor to react uniformly on a bad record; it is considerably harder to do correctly than you'd expect.
IV selection; yes, if you select the IVs correctly, you're safe; however this does leave open the possibility that an implementation doesn't select their IVs correctly.
Now, they could have reworked how CBC and HMAC works, e.g. HMAC the ciphertext instead, use deterministic but unpredictable (to someone who doesn't know the keys) IVs; they declined to do so.
