The behavior you are describing is what I would expect, the object events are being executed when they need to. In your question you are mixing the microflow activities and object events, these are two different things that have their own sequences.
Each object event has a before and an after state, for a create it doesn't make a big difference if you'd use before or after. When looking at a delete or commit the platform first executes the before microflow(s), does the database action, followed by the after microflow(s).
When looking at this through a microflow activity there are a few things happening.
For a create activity the following sequence of events is being executed:
0. We arrive at the activity and the platform starts evaluating
1. Execute the before Create Event microflow(s)
2. Create a new instance of the entity (and set the default values from the domain model)
3. Execute the after Create Event microflow(s)
4. Go through the list of attributes from top to bottom and set all attribute values
5. If Commit 'yes' is chosen go to step 2 of the Change/Commit activity
6. Goto next activity
For a Change Activity (with commit set to yes)
0. We arrive at the activity and the platform starts evaluating
1. Go through the list of attributes from top to bottom and set all attribute values
2. Execute the before Commit Event microflow(s)
3. Write all changes to the database (platform knows if it's insert or update)
4. Execute the after Commit Event microflow(s)
5. Goto next activity
@Jasper: Thanks for taking the time to write out this clear answer. I do however not agree with your statement that this works as expected. This seems to work as expected from a Mendix platform developer point of view (you), but not form a Mendix developer point of view (op and me). If we could quiz this properly I would definitely put my money on most people having the same expectation as op.