I'm coding a multiplayer game and from what i've read in some different articles about game networking i should choose UDP + unreliable packets for game state updates. So i chose ENet library (since it's built upon UDP). Any combination of flags other than pure ENET_PACKET_FLAG_RELIABLE causes incredibly jittery and unplayable experience. This happens even if the server and client are running on the same machine (latency being close to zero). I presume it's a problem of a packet loss but why on earth would that happen so often on a local host?

First check if is really a packet loss issue. A simple method would be to give every outgoing packet a unique id (simple sequence number) and output it on the other side. Check if you really encounter packet loss or if you have an issue with the incoming order (packets are unordered). The later could result in jittering, which should be solved by remembering the last unique sequence number you have received and ignore any state update packet with a lower sequence number.

I thought this functionality was provided by ENet itself? isn't it?

The point of the suggestion above is likely to add your own instrumentation on top of the ENet layer, so that you can see how it actually behaves with your game data.

It may be that you're not getting what you think you're getting. Or it may be that you're using ENet wrong. Or it may be that your network is actually really bad. Or it may be that the "jitter" is actually caused by local thread scheduling problems, rather than networking. Or something else -- there are lots of possibilities.

I'm guessing you're not doing client-side extrapolation/interpolation and instead just rendering at raw update positions - this would make it look "jumpy" if the camera is still, or "jittery" if the camera is moving... To make it smooth you need to do extrapolation/interpolation