DTLS vs direct use of AES. What are the threats unique for direct use of AES instead of DTLS?

You appear to be quite familiar with the issues you face already, but I'm going to answer your question as literally stated nevertheless.

1. AES is a block cipher, so it needs to be used in a mode-of-operation in order to provide proper privacy (IND-CPA).

2. AES is a block cipher, so it needs to be used in a mode-of-operation in order to provide proper integrity (IND-CTXT).

3. Even with a good mode-of-operation (like AES-CCM), you don't get protection from replaying, reordering, and dropping of messages. For this you need a stateful mode-of-operation. What should this state be? It could simply be a number, but it doesn't necessarily have to be. In any case, this state needs to be managed and synchronized correctly between the two communicating parties. Can be tricky.

   But in addition to this, you also need a choice of policy: do you allow messages to be dropped, but not reordered? Do you allow messages to be reordered, but not replayed? Do you allow some messages to be replayed/reordered within some window of acceptance? ...and so on, for any complicated combination of the above. Suffice it to say, getting this right can be subtle.

DTLS gives you all of the above. The question is, can you do it better? In theory it is certainly possible. But in the end you would probably end up with something which is very close to DTLS anyway. However, now you would have to implement all of this by yourself, giving you all of the problems associated with implementing cryptography that you are probably well aware of.

Ultimately, if DTLS gives you all of this out-of-the box, then trying to come up with something that replaces it strikes me as having a high risk of introducing problems and for relatively little reward. Thus, why not simply use DTLS? Or even better, use something built on top of (D)TLS which is explicitly designed for the IoT domain (like E4)?