TL;DR - In the sense of semantic versioning, in my opinion, releasing every merge to main will lead to too many releases, that are not mapped coherently to end user value, or to milestones in the development cycle. Instead, merges to main should be marked with some other identifier, and releases should be done less frequently via a process that takes into account development and end user considerations.
As you probably know, semantic versioning assigns version numbers as major.minor.patch. The question of whether to do a version increment, or not, in response to a merge to main, depends on several considerations. It can be viable, but you need to consider factors like:
Your unit test, smoke test, and system test suite, and how often they are run. It may be reasonable to run some unit tests every commit, but due to runtime or overhead, some more extensive tests may only be run on major or minor releases.
Your build and deployment infrastructure. Are you able to do a full build every PR commit, or again, is build and deployment complex enough that it's only done for minor or major releases?
Your cadence of development and code review, and how often
development branches are getting merged to main, and after what
process of review.How rapidly third party dependencies are changing, and whether a
change in configuration requires additional testing or accreditation before deployment.And of course, how what you develop, and how you label releases, maps to the value to end users, as expressed in requirements and user stories, and as developed via sprints and epics, assuming some sort of agile development process.
These are some of the considerations I would weigh before deciding when to increment versions - there is no "always right" answer IMO.