The event pipe structure should be OK for the tag counts you're talking about. I've personally seen ProcessBook displays that have thousands of data points on them, so it can definately be done. The things to watch out for are:
1. Check the event pipe often enough and pull the data out of it. If you let a lot of data queue up on the server for your pipe, it begins to eat RAM and CPU cycles to manage it. It also becomes a large chuck to pull across the wire and then loop through in your client code. Check early and check often (but not too often) is the mantra for event pipes with large tag counts.
2. Understand that while a lot of the event pipe work happens on background threads in the SDK, the connection to the server is still a single potential bottle neck. If you have a lot going on in the event pipe world, it's possible to run into contention for SDK resources in other places in your code and therefore see performance issues that are hard to track down. I'm not thinking this will be a problem for you specifically, as I'm assuming that alarm tags, in general, have a very low event rate.
3. There are tuning parameters for the PI Update Manager service on the PI Server that dicatate the number of events that can be held for a single client, and in totoal for the PI Server. Check you PI Server manuals for an explination of the defaults for your version, and then decide if you need to increase these parameters. Again, with what I expect your event rate to be - you're probably OK with the defaults.
BTW, there's very little benefit to breaking up the tags into multiple pipes. No point in bothering with the extra code / management on your part.
That helps a great deal, and I will definitely take a look at the PI Update Manager parameters, just in case.