Comparing algorithm speeds is a difficult art. ChaCha20 is faster than AES on "small to medium" CPU, basically from the ARM Cortex M0 at one end of the range, up to Intel Core2. More recent "big" CPU have dedicated opcodes for AES (and this includes some ARM processors on smartphones) and this makes AES consistently faster than ChaCha20 on these CPU. For very small CPU, I don't have figures at hand, but I would expect the 32-bit additions in ChaCha20 to imply a hit, as well as requiring more RAM. This extends to hardware circuits (FPGA, ASIC): making an efficient circuit for AES seems easier than an efficient circuit for ChaCha20. Thus, small 8-bit CPU can be more easily expanded with an AES accelerator than a ChaCha20 accelerator.
Another point is that AES is a block cipher, i.e. a relatively versatile primitive that can be used to encrypt data, but also for other tasks in which ChaCha20 is not an obvious drop-in replacement. This makes such comparisons delicate.
However, none of this implies that AES is perfect. It mostly means that making a function that behaves better on most architecture where AES runs is a challenging task, and ChaCha20 is an incomplete solution to that.
An additional parameter is side-channel attacks. It is well-known that table-based classic AES implementations are susceptible to cache attacks (timing attacks that exploit the common behaviour of cache memory). A more recent trend is to point out that ARX designs like ChaCha20 ("ARX" = "add-rotate-xor"), apart from their relatively high cost in hardware (because of the carry propagation in adders), might be more susceptible to fault attacks. Thus a blooming branch of cryptography hard at work trying to design alternate solutions; e.g. Gimli. This latter example is a good illustration of modern fashions in several ways:
A non-ARX, non-table design: no S-box (contrary to AES or DES), but no "complicated" operation like a 32-bit addition either (contrary to ChaCha20).
It is not a stream or block cipher; it is an un-keyed permutation, which is meant to be used as primitive to build higher-level functions, such as, indeed, encryption, but also hashing or MAC.
To sum up, while AES has known shortcomings, there is not a single, obvious and clear replacement strategy. We have lots of interesting ideas and possible designs, and their shortcomings are still largely unexplored. Therefore, a cautious normalization entity like NIST should adopt a wait-and-see posture. Consequently, I don't expect an AES-replacement competition within the next few years.
(In fact, considering that some big parts of the industry, e.g. banking, are only just now beginning to switch from DES to AES, I'd say that we'll have to support AES for another 20 years at least.)