Regarding Saves and the main Twine Story Formats.
Any of the Story Formats that support the saving of Progress History, like Chapbook's "automatic" saving after each Passage Transition, or like SugarCube's & Harlowe's manual "slot based" saving, stores those saves in the localStorage cache of the end-user's web-browser.
Web-browsers generally allow a maximum of between 2 and 5 MBs of data per Domain to be stored in the localStorage cache, and weither the maximum is 2 or 5 MB depends on things like if the web-browser is being run on a mobile device or a desktop/laptop.
Some web-browser brands (like Chrome) treat all HTML files that are opened locally as if they are part of the same Domain, which means all such opened HTML files have to share the same 2 to 5 MB of storage space.
So far all the restrictions on the storage space available to save Progress History in have nothing to do with Twine itself, or its Story Formats.
Project Authors have total control over the number of (Story/Global/Stateful) Variables their project has, and over the amount of data they store in those variables.
It should be obvious that the more stateful data a project creates & tracks, the large Progress History becomes, and the larger a Save needs to be to store a snapshot of that Progress History.
So while the Twine Story Formats can do things internally to compress the data being tracked, and to reduce the time it takes to preform Progress History tracking related actions on that data during the Passage Transition phase. At the end of the day it is the Author's choices about what to track and how long to track it for that really influences how many "saves" can be done.
eg. If each Moment in History is tracking only 10KB of data, and the Author has decided there is a maximum of one Moment in History at any time, and the end-user has decided not to open HTML file locally using Chrome or on mobile device, then that can be a vary large number of Save slots.