Not sure how I can summarize it any better, except perhaps to mention that all access to a list's data has the pre-filters applied to it, not just the list view. Pre-filters are access control mechanisms, not just list display filters (that's what the element filters are for). So when you load (say) a form or details view, the list pre-filters will be applied. And if your event_id query string is not present on the details view URL, the pre-filter won't work.
You were loading your list view with your event_id query string, but the standard details view links in the list display do not automagically include (custom) query string args that are present on the URL that loads the list. We just construct a normal details link, with option=com_fabrik&view=details&formid=X&rowid=Y (and an itemid if applicable). The event_id=Z from your list's URL won't get included.
Hence, you need to use a custom details view link, which adds your custom query string name and value. The {event_id} placeholder you are using in your custom link will be replaced with the value of the event_id query string you are loading the list with.
The reason we don't automatically pass query string args through to form/detail view links is that often you really don't want that to happen, and it could cause unwanted behavior on the form/details view. For example, if you are filtering a list with &table___element=foo, passing that through to a form view (wjere it would be interpreted as a default value) could have undesired effects (or might be what you wanted ... but we don't know that). We don't have the a-priori knowledge of which ones you do want to use, so rather than try to be clever (like, say, looking for what looks like query string args used in a pre-filter and include those), we just leave that decision up to you.
-- hugh