A "fossil rollback" command is problematic, for two reasons.

The first and less serious reason is that removing information from a
fossil repository goes against the fossil philosophy of preserving all
changes.  There are other mechanisms in place to remove content from
a fossil repository (ex: the "shun" mechanism) but these things are
intended to combat spam.  We have concerns about users routinely
backing out their changes.

The second problem is that the rollback can only occur on the local
repository.  If a sync has occurred since the commit, then the commit
has already been replicated onto other repositories.  The next time
the local repository syncs, the commit will reappear from the remote
repository and the rollback will be undone.  Note also that the default
behavior is for the local repository to sync automatically after each
commit, so there is a strong change that a sync will have occurred in
between the commit and the rollback.

What exactly is the OP hoping to accomplish with a "rollback" command
in fossil?  There are two opportunities during the commit process to
abandon the commit - while editing the check-in command and while
entering the GPG password - so it seems unlikely that a commit might
occur by accident.  What problem would the "rollback" command solve?