mbed tls DTLS v1.2 system with -ECDHE-ECDSA, mutual auth and pre-installed public/private keys, no unnecessary messages or ASN.1/X.509 decoding
You can write your own protocol instead of using DTLS. But there's no realistic chance that you'll get it right. Designing a secure protocol is hard, and you should definitely use a proven and tested one rather than roll your own.

You can do DTLS with raw public keys, which would avoid X.509 altogether. This saves a number of things: code size, RAM usage (but not a lot, compared to a self-signed certificate), and handshake message size. You still need two round trips to establish a session using raw public keys. This does have security and deployment drawbacks: you have to distribute all the peers' public keys before you can start communicating, and you have to manage repudiation on your own.

If you find an implementation of it, that is. Mbed TLS doesn't support it, although there's an old pull request for it. Reportedly tinydtls can do it.

Do use session caching and resumption whenever possible. Session resumption removes the cost of public-key cryptography and reduces the number of round trips to start the connection from 2 to 1.

TLS 1.3 will let you establish a session with a single round trip, but DTLS 1.3 isn't ready yet.

In the absence of a usable implementation of DTLS with raw public keys, you may be forced to partially roll your own: use DTLS with pre-shared symmetric keys (this is widely supported by (D)TLS implementations), and use a separate protocol to distribute the symmetric keys. But it would be safer to achieve this by using DTLS to effectively distribute the symmetric keys, and session resumption to avoid doing asymmetric cryptography every time.