Potential Solutions
1. Use ogr to read in spatial data. This works fine, and you can query features using the ExecuteSQL() functionality. The problem is when you get into modifying geometry (aggregating, simplifying, etc). For this, new objects would have to be created using a library like Shapely and that API could be used to to the geometric operations.
2. Use spatialite to store, query, and do geometric operations on all data. ogr can be used to convert data to spatialite, and spatialite has native support for reading shapefiles. All query and geometric operations could be performed within the database.
#2 is a pretty attractive approach for the stylesheet authoring workflow. Data could be imported into the database and indexed only the first time the stylesheet is rendered. The database could also be used to cache derived products like simplified shapes or aggregations to speed up rendering. This would mean that the author could make tweaks to the stylesheet and very rapidly see them rendered. Spatialite is available as a self-contained binary and involves no setup of new databases, so these benefits would be realized without the complexity of something like PostGIS.
The problem with that approach is that it doesn't work very well for a scenario where the stylesheet is already authored, but you want to integrate it into something like django to render on constantly changing data found in PostGIS. It would be nice to have a solution that worked well for both these use cases. If a solution can't be found though or is too complex to start with the authoring workflow should be the priority.
Current Plan: try doing things with ogr and the ogr python bindings or geodjango wrapper and see how things go doing everything outside a database.