I really like it, when some people say something is the "easiest way" to do something (and your comment suggests, that you do not know much about both computer science and programming).
Anyway, as this game is written in sugarcube and has images and audio files as resources (and also fonts), the game does not consist of just one file, but encompasses multiple files.
Images and audio files, which are for non-public versions only, could be put into other folders (ie. using pics_tier2, pics_tier4, sounds_tier2, sounds_tier4 instead of pics and sounds folder).
That way it would be easier,, when making the zip-file for the game, to not have pics (and sounds) for a non-public version appear in the public version (ie. as it was forgotten, to remove an image or audio-file from the folder to be zipped). Of course one could automate the process, ie. having a script (or small programm) do the packaging (see ie. "ant" or "antlr") and having a metadata file (or property file), which has for each and every image, audio (and font) file stored in which package the image, audio and font file is to be included.
Now to the html-file (or html-files) with the game itself:
Neither html or sugarcube are programming languages like "brainfuck" or "whitespace", which are hard to read, also neither html or sugarcube yield programms, which do need compilation into machine code (bytecode) or something like that for the programm to be runnable. Which means that people with some background in computer science (or some expertise in programming) can easily read and understand what the program does (especially since a few things, which some websites do to make it harder to download video files from their site, are not done) - otherwise it would need "reverse-engineering" (and some guess-work as what a variable and function are used for...). So if somehow some tier-only game data (like quests etc.) end up in a public version, even if it does not function (out-of-the-box) without some editing of the game files, people with some knowledge in programming can modify the game file(s), so that it does function (ie. a quest or some parts of a quest become(s) available) - people without such knowledge might screw-up their gamefiles instead.
Now you can think of the gamefile(s) (without the resource files) as one "master copy", which contains all the code for all different game versions (where game version refers to the public version and the different tiered versions). And removing the code for all tiered versions from the "master copy" yields the public version and removing the code for higher tiered versions from the "master copy" would give a tiered-version (ie. tier2 version instead of tier4 version).
The "problem" is how to make sure, that by removing code (from "higher" versions, where higher version means higher tiered-version or all-tiered versions, in case of "public version") you do not miss to remove code that does not belong to that version, while also making sure, that the code is still working (after code removal).
If the "master copy" does contain the code in explicit form (ie. during the execution of the code no new game code is generated, ie. via DOM-scrips (Document Object Model scripts) or javascript) and the "master copy" is also one file (or multiple files) - eg. one does not manage separate (stand-alone) copies for the public and tiered versions - then you would need to remove the code either manually or in an automated way.
As the game is written in "sugarcube" (or twine script) this would mean that ie. "complete game passages" are to be removed and also from some game passages code might need to be removed (at least if no separate stand-alone copies for the different versions are maintained, but bugfixing and changing game mechanics might be a little bit more difficult if standalone copies are used, ie. as a bugfix would need to be made to multiple versions - so maintaining the code does require more work from the developer).
Of course it is easier to remove complete game passages from the game (in comparison to removing only some code blocks from a passage), without "breaking" something or missing some code which does not belong into the public (or low tiered) version. But it is more complicated to structure the game code in such a way, that all tiered-only game code is only in separate game passages. For quest texts and quest rewards (etc.) this is relatively easy doable (ie. via using "include passagename" or link statements etc.) and having ie. definitions for "pois" in the public version (which are not used in the public version) are also no problem (it only becomes a problem, if the quest data itself including quest rewards are also somehow in the public version). For some other "features", like tier-only traits, which give boosts to some "chances" (ie. change some game mechanics slightly), it is a little bit more complicated, eventhough also "include passagename" can be used here, but then the code for the game mechanics themself are a little less readable (for the developer himself) - and there are also a few more complications (in contrast to additional quests, renders or tasks for tiered-versions), when it is desired that a one-time supporter also has some benefits with newer versions (ie. still being able to do tier-gated quests, enjoying tier-only mc-traits, with a game started with a tiered-version but then patched to a newer version). (Ie. making it possible that old tiered-version game passages are included into a newer public version instead of new tiered-version game passages (with the same name)).
And as this game is still in development, when code is marked in a "master copy" (ie. via comments or otherwise) as tiered-only content, the code might get moved around during "tech revamps" etc. and it might happen that the code markers (for tiered-only content) are not moved, when some tiered-only code is moved from one location (in the game file) to another as it is overlooked that the code is between such code markers (ie. the code blocks being too large to fit on the screen and not paying enough attention when moving the code around, that it was tiered-only content, which ends up outside of codemarkers for tiered-only content). In case of code, which is in tier-only passages, the chance of such things happening is much lower (especially if it is moved from one tier-only passage to another tier-only passage).
Single player games, which run on ones own laptop (or personal computer) and do not need any form of internet-connection (to function), will always be modifiable (or modable) by people with enough knowledge in some things (at least as long as there are still free operating systems and big tech companies and the content industry have not made their dream come true, that they have complete control over all computers of would-be customers).
And then, as this game is a single-player game (and thus the term "pay to win" for "free to play" games is not really applicable), there is nothing wrong with giving game supporters additional benefits (out-of-the-box)¹, but what needs to be kept in mind is, that there are one-time supporters and long-term supporters and thus there are arguments for letting one-time supporters still have some benefits with newer versions. This needs to be kept in mind, when deciding on a solution (or lobbying for some solution) - and the developer might have also considered this, when he did chose how to handle content for the different tiers in the first place.
¹) Non-supporters can always write code (without knowledge of the tiered-content) which might give similiar advantages (or benefits) as tiered-content (only in case of quests, tasks and additional "lore texts", this is unlikely).
