sk_buffs typically represent network packets. They can be generated as a result of a write to a particular socket by a particular process but they can also come into existence in other ways.
When a packet is received from a network device, for example, it is placed in an sk_buff. As it is passed up the stack, it may be processed by various modules and layers (IP, ARP, UDP/TCP, as well as things like "tap" devices). Some of those modules may need to do something with the packet that is not instantaneous (example: retransmit on a tap device). And of course, data from the packet might also be delivered to a process reading from a socket.
A component needing to process the packet data could of course simply create a copy of the packet buffer, but if no other component will be modifying it, that would be wasteful. So, incrementing the users count allows the module to put a "hold" on the packet so that it won't be freed -- and hence the underlying memory won't get re-used for some other purpose -- as long as the module still needs it. As the users of the sk_buff finish using it one-by-one, they decrement the users count and when it becomes zero then the memory is released.