I'm not sure "centralizing" the subscriptions into one or two tables is necessarily going to make them easier to configure, but if you are going to attempt it then something like option 3 is your best bet. The DDS query can contain any logic necessary to combine subscriber details and parameter values, as long as it returns one row per subscriber.
If your subscription delivery requirements are complex, you could look at using a third-party tool to help manage them, e.g. http://www.christiansteven.com/solutions/sql-rd/