Performing "Optimize for Reporting" on a property within an embedded Page List property will use a separate table (creating a new one if necessary) and create/update a Declare Index rule that orchestrates saving a copy of the 1-to-many data from within your Page List to the separate table.
Note that optimizing top-level single value properties, as well as properties within an Embedded Single Page property, will be stored on in the same table as the work item. These properties have a 1-to-1 relationship to the work item, and Pega does not need to keep them in a separate table.
The Declare Index will take care of managing the "foreign key" back to the work item, as well as unique identifiers for your 1-to-many data (based on the name of the page list and the list index number). The Declare Index also handles cleaning-up (deleting) your 1-to-many data if you remove elements from the Page List.
The main advantage is that the data in the table managed by the Declare Index is always synchronized with the content of your work item every time it is saved. You don't have to configure anything specially in Pega once the Optimization wizard is run - it happens for free. This is particularly useful if you have Page Lists within Page Lists and have an intricate set of 1-to-many-to-many relationships [e.g. LoanApplication.Applicants().Addresses()] . Pega's Declare Indexes deal with all of that when it commits saves; you just focus on configuring your case type and let Pega worry about the physical data model needed to support your reporting/retrieval requirements.
If for some reason you need to take full control over storing a copy of your complex type data embedded within your work object, I'd recommend using a Declare Trigger so that what you store for this is synchronized with what is saved from Pega, regardless of what triggers the save. This takes away the need to wire in invocations in your Flow Actions, for there are very many other ways a work item is changed and saved in Pega than just performing Flow Actions. The downside is that everything the Declare Index does for you OOTB (described above), you have to configure and test yourself. This is proven Pega capability - leave Pega to do it.
Savable Data Pages are more for saving changes to related non-case data back to the System of Record from where they were retrieved (be it Pega or something else) at certain points in your case lifecycle where that related data is known to have changed and is ready to store. I don't think Savable Data Pages are a fit here, for as you've alluded to, you need to explicitly invoke the Save operation when this data is known to be good, and the typical usage is to couple them to Flow Actions or Flows.
Something to think about though ... if your goal was to store the work item's embedded complex data in the relational database of a different system, having Savable Data Pages represent your data types that are stored externally and wiring them into a Declare Trigger activity on your Case Type would be the right mix of storing external data and ensuring this occurs on every work item save.