This scenario is interesting and got me thinking. I can come with some pointers to consider,
1. Wwhen a Child object is created a new entry is added to the Child table in DB
2. At the same time a new entry with the same GUID is added in the Parent table as well. Since the Child is specialized from Parent.
3. Now you can retrieve a Parent object and it can be casted out as Child object among other specialized objects through inheritance split.
4. So one cannot be certain as to the Parent object being retrieved from DB is a Parent object or one of the specialized Child objects.
5. Hence my theory is since there's a chance of a Parent object being a Child object itself there's this lightning bolt :) showing up just in case to invoke the event handlers associated to that Child object.
PS: Just sharing my thoughts. Purely theoretical unless proven or agreed upon.
Tested this scenario in Mx 7.13.1:
CHILD is specialization of PARENT
CHILD has a before commit action, PARENT does not.
Created an object of type CHILD.
Using the PARENT as the input for a microflow a commit action and a change action will show the lightning symbol, and will trigger the before commit event for the CHILD object while commiting the PARENT object.
Using an inheritance split and a cast to the CHILD object from the PARENT the change object action and Commit action will also both show the lightning symbol and trigger the before commit action.
My question would be how did you get to the statement: ".... the BCO event only triggers on the CHILD commit."
I'm seeing that this triggers both on the PARENT and CHILD, and as these are the same objects it seems to make sense that the before commit event is triggered in both cases. Maybe specific for the MX version you are using?