Suppose we have a simple code consisting of the three words cat, catapult, and camel.
This set of codewords is not prefix-free, because a (whole) codeword, namely cat, is also a prefix of another codeword.
Here is a (fake) illustration of the problem this can cause. Suppose that cat encodes "run like h***", catapult encodes "having a good time", and "catenary" encodes "when's dinner?".
Imagine now that codewords come in kind of slowly, letter by letter. If you get the letters $\text{c$\qquad$ a$\qquad$ t}$ you don't know what to do, this might be the complete message, so you better stop staring at the computer screen and get out of there fast, or maybe it is the beginning of another codeword, and you better wait.
Suppose by contrast that the only codewords are catch, catapult, catenary, and catamount. This collection of codewords is prefix-free, since no (whole) codeword is the beginning part of another codeword. If $\text{c$\qquad$ a$\qquad$ t} \qquad\qquad \text{or even} \qquad\qquad \text{c$\qquad$ a$\qquad$ t$\qquad$a}$ comes in, you know you have to wait in order to get the message.
At a more programming level, suppose that letters come in in a steady stream, not separated into codewords. You want to be able to separate this stream of letters into codewords "on the fly."
If both cat and catapult are codewords, if you see cat you can't make the decision until you see the next letter. That's why the first example is not prefix-free.
In the second example, there is no problem, if you see cat, you know it is not in the codeword list, so you wait for the rest.
Comment: There are some good reasons to use variable-length codes. For example, suppose that our messages overwhelmingly consist of numerical information, with very brief pieces of text. Then it can increase throughput a lot to encode digits as very short bit strings, and letters of the alphabet as longer bit strings.
In a language meant to be interpreted by a computer, it is often convenient to have the prefix-free property, because it can mean that we can use a simpler parser. A parser that has to do a fair amount of "looking ahead" in order to interpret a string decreases efficiency.