Any reason as to why we do not leave in this code at this point to handle re-starting clients?

In my opinion, a"client restart" is not related to MAC violation.
it's related to a CLIENT_HELLO in epoch 0. That needs to be challenged by a HELLO_VERIFY_REQUEST in stateless manor. If that succeeds, a "verified" CLIENT_HELLO of epoch 0 starts a handshake.
(See my PR #89 for more details about stateless CLIENT_HELLO processing.)

OK. Thinking about it, epoch 0 for a client restart will cause the security context to not be found (about line 4062) and so will never get as far as this code.

Maybe, it's important to refer to RFC6347, 4.1.2.7

4.1.2.7. Handling Invalid Records

Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.). In general, invalid records
SHOULD be silently discarded, thus preserving the association;
however, an error MAY be logged for diagnostic purposes.
Implementations which choose to generate an alert instead, MUST
generate fatal level alerts to avoid attacks where the attacker
repeatedly probes the implementation to see how it responds to
various types of error. Note that if DTLS is run over UDP, then any
implementation which does this will be extremely susceptible to
denial-of-service (DoS) attacks because UDP forgery is so easy.
Thus, this practice is NOT RECOMMENDED for such transports.

For me, that includes, that invalid MACs don't trigger a new handshake.
But CLIENT_HELLOs with epoch 0, as in RFC6347, 4.2.8

This will appear to the server as a new handshake with epoch=0. In
cases where a server believes it has an existing association on a
given host/port quartet and it receives an epoch=0 ClientHello, it
SHOULD proceed with a new handshake but MUST NOT destroy the existing
association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message.

Therefore: special stateless processing until the cookie is verified.

(And, yes, currently processing the handshake messages may cause also alerts, but for me this is again a different story. This one is about invalid MACs and ignoring them. No alerts, no removing of peers and no new handshake are caused by invalid record-MACs.

Oh - and a bad epoch with therefore cause libcoap to tear the connection down as -1 is returned. I will fix this.

OK. Thinking about it, epoch 0 for a client restart will cause the security context to not be found (about line 4062) and so will never get as far as this code.

Even more:
CLIENT_HELLOs with epoch 0 will be process ahead of any of the these checks. No access to the peer via peer = dtls_get_peer(ctx, session);. No anti-replay protection. No decrypt_verify. A new peer and handshake on the server-side is created, when the cookie is verified in the new handle_client_hello, nowhere else. Only after the peer and handshake is created, other received records will be processed for that peer. Other records without a peer, will silently be dropped.

Oh - and a bad epoch with therefore cause libcoap to tear the connection down as -1 is returned.

Yes, that would be introduced by PR #85, which changed data_length = -1; into return -1;.

Without PR #85, using

      if (!security) {
        dtls_alert("No security context for epoch: %i\n", dtls_get_epoch(header));
        data_length = -1;

and this PR, it will be ignored.

It is looking more like #85 has been superseded.

#85 has been superseded.

Yes, I should have mention that ...

This needs to be correctly indented.

Hope, it's fixed :-).

Are there any "formattter" to apply?

CONTRIBUTE.md has TinyDTLS coding style. I am aware of a lot of TABs being used, along with white space at ends of a line all of which need tidying up at some point.

Yes, especially the whitespace formatting is broken at some places :-(

Hopefully, not longer in the lines of this PR ;-).