1. If you are using events, you first have to create the subscription by specifying which entity you wish to track and what types of changes you are watching for (e.g. INSERT, UPDATE, or DELETE). The GET event/subscription then returns any of those events since the last time you checked (or since the subscription was created if this is the first time checking).
2. You can use events, or you can use the EditHistory entities. Each entity has an EditHistory (e.g. CandidateEditHistory) that can be accessed via the api. (Note: This may only be available with certain licenses). The XEditHistory entity then as associated XEditHistoryFieldChange entities tracking the changes to the individual fields.
3. It depends on how the record was deleted. If it was a soft delete (e.g. just an update setting the isDeleted field to true), then you should be able to see the edit history. If it was a hard delete, it was removed from the database altogether and I my guess is the XEditHistory records may also be deleted, but I'm not 100% sure. It would be a nice feature to keep the XEditHistory entity since that would give you a way to see permanently deleted records.
4. The "event" is the actual insert, update, or delete event and the subscription is the collection of those events. For example a subscription called "JobOrderUpdates" created to watch for "UPDATE" would contain update events on the JobOrder entities.
5. If you are tracking data with an event subscription, the call to the subscription returns an array of events. Each event contains the id of the entity being changed along with the event type. If the entity was updated, each event contains an array of properties that were changed.