For me it makes more sense as then I don't need to re-parse if errors occur when sending the email for example.
In such a case, the main decision criteria are simplicity and performance (which depend not only on the process you are implementing, but also how you do it).
For example, when the running time for re-parsing the input file is negligible, and you need the full data of the excel sheet again in case of an email sending error, it will probably be simpler and faster to reparse the excel file again and not take the burden of storing the data in a database first, and retrieving it again when the email has to be resent. Reparsing the same data twice is not "bad" just because it happens twice, as long as it gives you reliably the same output from the same input, and as long as the parsing does not involve a complex, very slow transformation process.
If the parsing itself can show up errors which must be corrected first (maybe the spreadsheet has not the expected structure?), or if there is a clean-up step involved, the situation starts to change. Then you need an additional intermediate data store for the cleaned data anyway. That could be a new Excel file, of course, and that may be still the most simple solution. But if one needs to integrate additional data from other data sources as well, if you need to enforce some kind of relational constraints on the data, some kind of lightweight database might be a solution which serves you better.
However, lets assume you will have to generate 1000 emails from one excel file, each based on a different part of the data in the file. Now in the process of sending the mails, 5 of the mails come back and you need to retrieve the data for exactly those 5 receivers for preparing a resend. For such a case chances are high that by using database to re-query exactly the needed data only for those 5 persons, you can make the process simpler and faster. And if you need to store additional metadata like how many sending attempts for each receiver you had, a database gives you a place where you can introduce additional tables or columns for this metadata.
So the answer is it depends. A database introduces additional overhead, but also gives you benefits, this is a trade-off. And if you currently do not know the upcoming requirements well enough, start with the simpler approach first (which is probably not using a database initially), but make sure your HTML generation uses some intermediate data structures. That gives you the option to switch to a database later, when you get requirements that demand it.