The following remarks are made from the perspective of considering dark theme as a potential feature to be implemented.
Arguments
Consider carefully if planning to with dark mode as default and only option.
Potential energy savings (depends on display technology).
Some people might do better with dark mode.
Some users prefer dark mode better.
As always, remember context of use.
Research and planning
Understand the user goals and context.
Identify the target audience's preferences and needs.
Identify design elements that are important in the context.
Identify assets that are not themeable, e.g. source is outside of the solution scope.
Design and development
Dark theme requires separate color scheme: all colors need to be redefined.
Avoid saturated colors.
Consider carefully which colors are needed (e.g. button themes). The situations (combinations of colors) might differ by theme.
Custom dark theme colors that conflict with existing brand definitions is not a major problem. Readability, usability and visual balance trumps design guidelines.
Using saturated semantic colors simply do not work on dark theme. "Consistency" is not desired in this case.
Shadows don't work the same: communicate elevation with lightness.
Ensure all themes are accessible (WCAG).
Do not target mix-and-match theme system (combining elements from themes), not at first at least.
Even if different themes are not in the current scope or goal of the project, it makes sense to prepare CSS setup so that adding a theme, e.g. dark theme, is mostly about providing the toggling functionality and re-defining the colors. There is no valid reason to architect frontend components that does not support themes switching with relative ease.
Review and refinement
Gather feedback for all themes.
Users might consider your dark theme as "wrong" and revert back. This information might be lost easily.
Validate the selected technical approach. Prefer standard compliant approaches, e.g. "prefers-color-scheme".