I structured a project like this:
Characters hold a UID to a unique dictionary (one for abilities, another for effects). The dictionaries hold the UIDs for whatever abilities / effects are affecting that character. Basically, you will have a lot of picking objects from a UID reference.
I actually create objects for the effects and abilities, even though they arenʻt rendered, add them to a family, and add custom actions on those families. In this way you can abstract away alot of the common behavior like adding and removing abilities from the player. Once you have the boiler plate done, adding a new effect/ability is as simple as creating a new sprite, dropping it in the correct families, and then overriding the base custom action with whatever you need the new ability to do when it ticks.
Those abilities can simply be spawning bullets, explosions, particle effects or whatever you like. Just make sure you properly you have actions for removing an ability that ensures the ability also removes anything it adds to the game.
Since vampire survivor largely operate on automatic abilities, you donʻt have to worry too much about hooking input through this system, but if you needed to do that, you would probably need a number of "input actions" that abilities would check when being iterated through. Either that, or they would add themselves to another list that on succesful completion of the input action, and you would simply call them via callback. I typically use an input object that can be changed by either player or ai, and then a movement handler reads that input and responds accordingly. Hooking a system like that into the player abilities will be easy because each aspect is already isolated and doing its own thing.
If you have an extreme number of these objects linked like this, you will have performance issues. I make sure I only run foreach loops after filtering objects by other conditions. Also, iterating through arrays is faster than dictionaries, but the dictionary is faster to add and remove items arbitrarily, while the array handles pop/push more efficiently. I havenʻt tested queue, because I have had no need, but no optimization is needed until you have a problem anyway. In my case, I needed to be aware of this from the start because I knew I would have up to a 1000 lists to iterate through (each list having up to around 12 items)... basically, so long as you donʻt have to run picking events for 10k objects, you are fine.
Also, most games wouldnʻt need to actually create those objects but simply refference data stored somewhere in one place. I just.... happened to have specific reasons why I needed to go overboard on it.