The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage.
I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.
Just to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream.
(though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)
There is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.
A tool like pre-commit really helps here: it'll run against the staged files, before committing. Your CI tool really ought to be testing the commit too, at which point having a clean commit locally isn't necessary for correctness, only for avoiding needing to re-do your work.
It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.
I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.