So is such overflow the main or even only reason why OSC UDP messages can be lost?
Yes, buffer overflows are the main reason for UDP packet loss. When sending messages between programs on the same machine, there are only two buffers involved: the UDP socket send buffer and the UDP socket receive buffer. If the UDP send buffer is full, what happens depends on the OS: some may drop the packet, others may block until space is available. Same with the UDP socket receive buffer, but on most systems incoming packets are dropped if the buffer is full. The receive buffer can overflow if it is not big enough and the receiving application is too slow.
When sending UDP packets over the internet, there are many intermediate buffers involved - and consequently many more opportunities for packet loss 
Could adding a extra buffer in the receiving program help to avoid such data overflow?
First, you can increase the socket receive buffer size, either in the source code of the program (see SO_SNDBUF and SO_RCVBUF socket options), or globally with some OS-specific configurations. On some systems, the default socket buffer size is rather small, particularly on Windows.
Also, you can write your program in a way that the network receive thread receives packets as fast as possible and only puts them on the queue for another thread to process. This is how scsynth works. sclang, on the other hand, interprets OSC messages directly on the network thread; if the message handler takes too long, subsequent incoming messages might get lost…
Supercollider uses UDP by default? Are people using it with TCP as well? When?
Yes, it uses UDP by default. You can switch the Client/Server communication to TCP with the ServerOptions.protocol option. I don’t think many people do this, but it can help in situations where you send many, many messages in batches and you don’t want to bother with adding appropriate wait times.
Currently, sclang itself cannot act as a TCP server (i.e. accept incoming connections), but it can connect to TCP servers as a TCP client and subsequently receive messages. See also TCP input to SuperCollider.