I very strongly prefer a separate "nonwork_days" table. The table needs nothing only the date and a tinyint reason code for why that date is a nonwork day.
The big problem with a calendar table being used to determine nonwork days is that people rely on a host of flags to determine work days, viz:
SELECT COUNT(*) AS workdays_count FROM dbo.calendars WHERE is_weekend = 0 AND is_holiday = 0 ...
Now you have code in dozens or hundreds or more places each determining work days. Bad idea. Even more critically, what happens then if you need to work on a weekend day for some reason? It's almost impossible to do cleanly. What if you need to work on a holiday because of an emergency? (such as COVID or a fire or flood). Truly nearly impossible to do when code in hundreds of places is relying on "is_holiday" to control work logic.
You naturally can use a calendar table for other purposes, such as determining fiscal year, etc. But a basic calendar table should not be used for determining work days.
SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."