An additional example to complement the other answers: the classical zero-knowledge protocol of Goldwasser, Micali, and Rackoff, based on quadratic residuosity (here), is perfectly zero-knowledge (and its statistical soundness can be made negligibly small via sequential repetition). A long standing open problem has been to understand whether it remains zero-knowledge under parallel composition. It was recently shown in a sequence of papers, culminating with this paper and this paper, that under standard cryptographic assumption (here, LWE), it is provably not secure under parallel composition.
To complement the great answer of Mikero, I will also try to explain why the proof strategy used in the standalone setting will often break down in the concurrent setting. This provides an intuition of why the proofs must be refined, complementary to his pathological example.
Another way to understand the source of the difference between the standalone model and the UC model is the following: often, a proof of security will involve a simulator that interacts with the other parties, and manages to extract some specific value from this interaction, which he uses to simulate the protocol. In a real run of the protocol, however, this value can typically not be extracted, since it would break the security of the protocol. Hence, the simulator must, in some sense, be given some "additional power" over a normal player to be able to simulate the protocol (think about zero-knowledge proof: clearly, if the prover could simulate the proof without knowing the witness, which the simulator must do, then this prover would break the soundness of the proof).
So, what is this additional power the simulator is given? It's the following: unlike a normal player, the simulator is given the code of its opponent. Hence, it can interact with this code as he like; in particular, he can uses what is known as a rewinding strategy: running the code with breakpoints and forking it at difference steps, to force some correlations to appear between the values computed by the opponent, from which the simulator extract some value (I'm being purposely vague here, but see for example my walkthrough here of such a strategy to prove soundness on an example zero-knowledge proof).
Rewinding is fine in a standalone setting: you can rerun (polynomially)many times the code to extract some value. However, imagine now the same protocol is ran many times concurrently. Now, you need to analyze the security of the full protocol. But the rewinding strategy might now fail: if the composed protocol has a nested structure, rewinding it might require recursive rewinds of its components, which can cause a rewinding explosion: even if the protocol consists only of polynomially many components, rewinding it requires exponentially many rewinds of the internal components. Therefore, even though a simulator can extract the appropriate values for each standalone run of the internal components, it will fail to use the rewinding strategy to extract the appropriate value from the full composed protocol.
This argument explains why a security proof which is perfectly fine in a standalone model might completely break down when concurrent composition is used. Sometimes, this is just an issue of the security analysis - maybe there is a clever way to avoid the rewinding explosion, or a different proof strategy that does not use rewinding at all, but sometimes, as in the case of the pathological example presented by Mikero, this failure to prove security stems in fact from the actual insecurity of the composed protocols.