What is the point of triggering CI/CD with an empty git commit?

I read posts (e.g., 1, 2, 3) that recommend triggering a CI build process by pushing an empty git commit.

I don't understand how this is a good idea as the commit history will be peppered with meaningless entries, and they can't be removed without re-writing the hashes (e.g., git rebase --interactive, anything from this list), so any clean-up will require a force push (which should be avoided if others also work on that branch).

For example,

BEFORE REBASE:

* c074c70 (HEAD -> master) yet another major item
* bd8e835 trigger CI
* 49ddd75 trigger CI
* f895e9f this is important
* a7da744 trigger CI
* cec6a60 trigger CI
* 96e84f7 init

$ git rebase --interactive 96e84f7

AFTER DROPPING ALL EMPTY COMMITS:

* e441b17 (HEAD -> master) yet another major item
* fc67d54 this is important
* 96e84f7 init

THE ONLY COMMIT THAT RETAINED IT'S ORIGINAL HASH IS "init".

Solution

Based on the comments, this is not a good general practice, and I believe the point of the mentioned posts is that

it can be done (but one probably shouldn't)
this can be used to test a CI/CD build service/system without having to add a contrived change.

It seems that a good general rule would be to push empty commits only to personal work branches, and remove them before a pull request and/or merging to master/main.

The thread Pushing empty commits to remote asks questions (see below) that would answer this same question but they have been completely ignored in that thread.

Are there any disadvantages/consequences of pushing empty commits? Is there any problem I might face in future because of this empty commit??

The GitHub gist why you should start with an empty commit for a new repo is only tangentially related here, but I found it interesting enough to include it here.