traceroute (UDP) lost packets

I am facing the following issue when running

between two nodes in the same subnet. This is done as a test whether the network connection between this 2 nodes is reliable or not. We were told to use this approach from a known DB vendor's Support Team. While running the command:

-s 10.1.3.205 -r 10.1.3.210

there are packets randomly not received, and no RTT is reported:

traceroute -s 10.1.3.205 -r 10.1.3.210
traceroute to 10.1.3.210 (10.1.3.210), 30 hops max, 60 byte packets
 1  10.1.3.210 (10.1.3.210)  0.152 ms  0.064 ms *

In opposite, running traceroute with option ICMP:

traceroute -I -s 10.1.3.205 -r 10.1.3.210

is reliable and no missing packets occur. The same issue was discovered on several Linux systems in our environment with different patch levels, different versions of traceroute and no matter whether system is a VM or physical. To simplify and for easier reading of tcpdump, I tried with the following command:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done

The output is the following:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.203 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.071 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.075 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  *
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.142 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.054 ms

Every 7th packet gets no response and this is reproducable. Now the Support team finalizes like we would have an issue in our network setup with this packet loss. Running the same loop with a delay of 1 sec. all 10 packets are sent and received:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; sleep 1; done

I am a little bit in doubt if this way of testing network reliability is correct or not, since usually traceroute is being used for monitoring of network path over routed connections. I tried a network connection test over several hours with

from SAP, where no lost connections where discovered. So is there anything obvious I have missed and is using

this way a feasible way to test network reliabilty?