Non-transferable
Transfers always revert, there is no way to switch it off, and that is exactly what the declaration is for.
All docs
transfer and transferFrom always revert with ERC20TransfersNotSupported, including for zero amounts and self-transfers. Only mint and burn move value.
approve still works and still emits Approval. An allowance on a token that cannot move is inert — harmless, but worth knowing if you infer intent from approvals.
No configuration
There is no setting and no way to switch it off. The module holds no storage at all, because making transferability switchable would turn the declaration into a claim you could not rely on. A token either can be transferred or cannot.
It is implemented as a check in phase one rather than by overriding the two public entry points, so every path that could move value is closed by the same three lines — including the fee module's exact-output transfers, and anything a future module adds.
If you run a market
If you run a pool, a lending market, or anything that has to move the token to function, this token cannot be listed. That is the point of it declaring so. The alternative is finding out when the first deposit reverts.
This module contradicts both the fee and the hook, so no assembly can install all five at once. The two self-declared reference tokens leave it out. The shared runtime carries it and gates it on registration, so a soulbound token is one of the subsets a verified clone can be initialised with.