Hello Naddy,
first of all I'd like to correct something (@Nicole, please do not get angry at me 
).
One workflow event can link more than one workflow. For example I do not like the SAP approach in the example workflows to build huge monolithic workflows. I prefere smaller ones which are better to maintain. Having more than one workflow linked to one event is not an issue especially if you are using start conditions / restrictions to reduce instances running for nothing. Of course if you are replacing the SAP example workflows by your own ones you have to ensure the examples are deactivated.
It is not sufficient to only activate the workflow event queue for the ERC_OBJECT CREATED event. All workflows which can be executed in the context of creating new objects or relations in eRec require the event queue. E.g. when an application is manually entered there are status changes very quickly after the creation. This is why also all ERC_OBJECT STATUSCHANGED linked workflows need the event queue.
Also note that the flag only has effect if the event queue is actually activated and the jobs are scheduled (both via TCode SWEQADM).
The most common cause for deactivation of an event linkage is an error. The standard setting for event linkage is to deactivate the linkage when an error occurs. In this case the system is sending a message to the workflow admin to inform him about the deactivation and the reason. As eRec is exposed to the web and there are simply errors from time to time I recommend to change the settings of all event linkages to "do not change" so an single issue is not stopping a complete workflow. Furthermore ensure that the workflow administrator is actually set to a person or a group of persons who are actually reading the messages. Would not be the first production system for which the workflow was set up by an external consultant and then this user was deleted so all important messages for the workflow administrator disappear.
Kind regards
Roman