Design: similar tables and foreign keys
Your questions, with my responses:


  
  Does event_config need a reference to event via event_id? It makes sense to know to which event the config belongs to, but at the same time it feels redundant since it's implicit from the relationship with dates.
  


Adding the event_id to the event_config table allows you to easily design a user-interface for modifying the event_config table, without needing a complex reference to an actual event instance.  This might be useful for "default" configs.

This also allows an easier code path for presenting data to the user prior to the user choosing a date.


  
  Isn't event_config an unneeded complexity? Its sole purpose is to provide shared fields to event_date and event_recurrence. Wouldn't it be better just to have the price and capacity columns both in date and recurrence?
  


event_config looks like a good optimization to me.  I see it as a way to manage configurations independently of specific events in time.  For instance, you might have a "holiday" config, a config for each weekday, and a config for "saturday" and "sunday", each of which might be exactly the same for each and every event that occurs on those days.  Why duplicate that data by storing the info in event_date and event_recurrence?