Events are triggered from various function modules only for OneOrder based transactions.

Most of them are called

during the CRM_ORDER_MAINTAIN call.

They always run in the background.

They can not be triggered by users

Registration is per Transaction Category per Event (sometimes you can give additional
parameters like status)

Logic is encapsulated function modules

Definition of new Events is not possible (in SAP standard)

Actions are triggered by the PostProcessingFramework (PPF). As mentioned before Actions are defined inside an
Action Profile.

Actions can run implicitly in background automatically (after save, after status change,...)

Actions can be explicitly triggered by the user (reference the PRINT of a document)

Action Profiles are assigned to a Transaction Type

For every Action it is possible to define a scheduling and a start condition

There are different types of actions like method calls or print of SmartForms

Action have an own log where you can see every Action (Execution, by whom, when,...)
Hope this sheds some light on the topic.
As a rule of thumb I always use Events for background application logic that requires no logging. Events are a
convenient entry point here to poke into the CRM_ORDER_MAINTAIN without modification.

Execute additional logic on SAVE or DELETE of a transaction

When a certain status is set

short: When the logic is executed very often

I always use Actions when

User input is involved or the logic should be explicitly triggered

For printing

When the executed action should be logged.

short: When the logic is executed seldomly

By the way: Do not use CRMV_EVENT to register custom events as this is a modification. In the transaction
customizing in the implementation guide there is an entry for this. (Though I have to admit that new function modules
have to be registered in CRMV_EVENT.)

In Event based frameworks, process flow will happen with internal event triggering where as
Post Processing/Requester based frameworks (Actions), will happen based up on user
request process flow.
Events are common for all users but Action can be varied for specific users.
When u want to send a mail on changing user status, though status is set by internal logic
(to use CRMV_EVENT), the mail should be send to particular person (it needs specification)
so Action is required.