Check my other post for what rules I've documented for ASAs. These rules are great for the first 7 rules if you've got an ASA. It will also handle a lot of other devices--although some exceptions are probably needed. Then you can process all the other devices.
It's near impossible to provide a one shoe fits all for any enterprise.
Syslog, by it's very nature, behaves differently per vendor, per hardware.
In general EMERGE, CRITICAL (Varies) & ALERTS (varies wildly) should be emailed. But some devices will sapm you with things at CRIT & ALERT that are not critical or worthy of alerting.
Find a GREP tool for the OSes you use. I prefer to perform GREPs right on the syslog server (Windows) rather that across network shares. Simply far faster. I use WinGRep, but the product doesn't function well past Server 2003--so I'm looking at other Windows GREP GUIs. Learning a good grep tool is vital to being able to get what you need to know from your logs.
How you organize--depends upon your enterprise and, to some degree, how you think. If you have a problem in CITY-A, do you want your logs segregated by Location (in most cases YES). If you have lots of WAN-to-WAN issues, you might prefer to have all your WAN routers logged to a single folder. We've broken them up by Distributions beneath a site. FW are separate usually due to sheer volume. We also separate wireless because it is a large volume and there is a lot that can be ignored on the wireless side.
Every segmentation requires a different rule and a different filter. So you will find limits to how much you can carve things up.
I can tell you the the WLAN controllers may send you thousands of ALERTS a day. Which you may be justified in ignore 100% of them. Other ALERTs form routers and switches you SHOULD be acting on. I don't know if I've seen an ALERT on a WLC that was worth an email.