DTLS vs direct use of AES. What are the threats unique for direct use of AES instead of DTLS? For regular traffic in mesh network (between Internet of Thing devices) customer decided to use one of two options:

DTLS PSK ciphersuite - DTLS based on pre-shared symmetric key
or direct use of AES - customer wants to minimize traffic between sleepy devices (battery should be alive for several months)

Questions:

What are the additional threats of second option (AES) that do not exist for first option (DTLS-PSK)?
How to mitigate these threats (say using AES in CBC or another mode and change IV, etc)? Not reinventing DTLS protocol manually and not with the same overheads as DTLS has.

There is mandatory requirement to share symmetric key between IoT devices within mesh network for regular traffic. This key fits for both options. (First joining of new device will use DTLS-PAKE - I mentioned this just in case - this is not important for this question).
Let's specify DTLS-PSK mode more exactly  - I'm going to use mbedTLS crypto library with define MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 is specified in cipher suite. Where CCM is mode for block ciphers that provides both authentication and confidentiality.
You appear to be quite familiar with the issues you face already, but I'm going to answer your question as literally stated nevertheless.

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

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

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)?