The "trigger" event in unity is very flexible: it can be set to fire on both dynamic and kinematic bodies, as long as one of them has a collider with the "trigger" flag. On the other hand, the "collision" event is limited to only dymanic bodies.
My question is: why do we need "collision" events at all - why not just always use "trigger" events?
[In other words: why does Unity include these two kinds of events and not just the "trigger"?]
The collision event represents a physics overlap that causes a collision resolution, altering the behaviour of one or both objects involved to make them bounce apart rather than pass through one another.
Collision resolution can only happen when one of the bodies involved is a dynamic Rigidbody. So this isn't a limitation of the collision event, this is simply the only time it's relevant or meaningful.
A static collider never moves, and a kinematic body overrides any collision resolution, so collisions between these colliders with no dynamic body involved don't produce any change in physics behaviour, and don't need to be processed by the collision resolution system that fires collision events.
Resolving a collision with a dynamic body requires additional information (and additional processing to generate it) that's not required for the simple overlap check of trigger events. This includes things like the contact points and normals making up the collision manifold, the physics materials of those contacting surfaces, the penetration/separation vector, the masses and momenta of each object, and the corresponding impulses to apply to each body to push them back apart.
The physics engine then exposes this information through the collision event in case user code needs to make use of it: say for spawning a dust cloud at each point of contact, or playing a sound based on the material at the hit location, or inflicting damage proportional to the resolution impulse, or altering the physics behaviour in response to the collision to simulate non-Newtonian objects, etc.
All this extra processing and data to pass makes the collision event a different beast than the trigger event, not just the same thing with a different name.
The separation also lets us distinguish between, say, a player entering the awareness trigger zone around an enemy, when we want to start its chase behaviour, versus the enemy colliding with the player, when we want to inflict damage. If both these applications used the same trigger message channel, we'd need to separate our scripts onto multiple objects to disambiguate which one happened.
Imagine you want a dent in a car or want to collide two cars into eachother. How will you determine impact/hit force ? Trigger doesn't return these functionalities
Perhaps you would like something akin to portal:
The cubes you can pick up have collision responses to everything to play scraping noises etc.
However the cubes only disappear when they pass through the blue light wall trigger volumes.
