Cryptographic hash functions must have several properties:
- Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x.
- Resistance to second-preimages: given m, it should be infeasible to find m' such that h(m) = h(m').
- Resistance to collisions: it should be infeasible to find m and m' such that m ≠ m' and h(m) = h(m').
These properties are not equivalent to each other, and you do not necessarily need all of them. It depends on the protocol in which you are using the hash function. For instance, hash functions are used at the initial step of digital signatures, for which collisions are not a problem -- unless the attacker is in position to choose an exact message to be signed. Details can be subtle.
If the hash function has an output of n bits, then there exist generic attacks which find preimages, second-preimages and collisions with cost, repsectively, 2n, 2n and 2n/2. A "generic" attack means that it works for all hash functions, regardless of how perfect they may be. This sets the maximum achievable security level.
If you "compress" SHA-256 output to 128 bits (whatever compression procedure you may want to use, even a simple truncation), then you are actually defining a new hash function with a 128-bit output. As such, the resistance to preimages and second-preimages of that function will be at best 2128, and resistance to collisions will be at best 264. Therefore, your truncated SHA-256 will offer "128-bit security" only in usage contexts where collisions are not an issue. But since it can be quite hard to ascertain that collisions are indeed not a problem, "compressing" hash function output is not recommended.
In general, we prefer to be safe than sorry; thus, when we want "128-bit security" we use a 256-bit hash function. That way, we don't have to worry about whether collisions could be leveraged into an actual attack or not. SHA-256 collisions are not feasible with existing technology.