I think the answer depends on exactly how you define "forced" soft fork. I find that this concept of a forced soft fork is mostly useful as a demonstration that being a soft fork (in the sense of "miners converge to a single chain as long as a majority enforces the new rules") is unrelated to how invasive a consensus change is to the ecosystem. If we actually want to discuss that impact, it's more informative to discuss it in terms of what old software/features remain functional/available.
Soft forks in general
As I suspect you already realized, it is certainly possible to add precision if you permit any kind of soft fork.
The easiest, and most extreme, way to show this is possible is through the mechanism described in the blog post by Peter Todd you linked above. A "Bitcoin 2.0" is introduced, with possibly entirely new rules, and higher precision, and the consensus rules say that new blocks must be empty apart from a coinbase transaction that contains a hash of the 2.0 block data. Old nodes don't see the new block data at all, and thus anything is possible there. The UTXO set of new nodes is "imported" by copying that of old nodes at activation time, adding the extra precision in the process.
This is a soft fork in the strict sense of the word, but it would render all old Bitcoin software (not just validation nodes, but all miners/wallets/indexers/libraries/infrastructure/...) useless as they won't see the new transactions at all.
As a one-way extension block
A somewhat less invasive - but possibly more complex - approach is possible.
The idea is to still have the "Bitcoin 2.0" block data from the previous section, with transactions that operate on a higher-precision UTXO set, committed to in the coinbase of old blocks. However, old transactions can still remain in the old blocks, visible to old nodes.
In this case, the UTXO set isn't migrated from old to new upon activation, but instead whenever coin owners want to move their funds over. A special address type is defined by the softfork on the old block side, and funds sent to it are burned from the perspective of old nodes, but magically revived on the new side.
Old software remains functional, but can only see and interact with non-migrated funds.
As a two-way extension block
It's possible to go even further, and permit coins to be moved both ways between the old and new world.
Instead of having a burn address on the old side, use a transfer address which looks like an anyone-can-spend output on the old side. To move funds back, a special burn transaction is defined on the new side, and when included in a block, miners are required to construct a transaction on the old side spending some of the outputs sent to the transfer address, bringing them back into circulation there.
This means that funds that are moved over once from the old side to the new side are not stuck there, and it is possible even to move everything back.
However, old software can still not see any transactions or UTXOs in the new world.
By truncating sub-sat amounts
It is possible to go even further on the "transparency-from-old-software" scale
Instead of having two entirely different worlds (different transactions, different UTXOs, different block area, ...), represent transaction outputs as just having the rounded-down-to-integral-sats amount as what is visible to old nodes, but with extra (ignored by old software) data somewhere in the transaction to convey the subsat value. This is about as close as one can get in terms of having old software still see the transactions and UTXO data.
With just that, it does mean that any old-node-visible sat that gets broken up into sub-sat amounts cannot be recombined into old-node-visible sats - the amounts just wouldn't balance out from the perspective of old nodes which violates their consensus rules. If that's not desired, this is probably the simplest possible approach.
This can be mitigated too, but at significant complexity. Any transaction which breaks down sats to sub-sats must have a special (according to old software) anyone-can-spend output with the broken-down sats. Any transaction which recombines sub-sats into sats is then allowed to consume such outputs (but only on the condition, to new software, that the sub-sat amounts balance out) to account for the difference. The complexity is that this effectively implies a shared "wallet" of these anyone-can-spend outputs managed by all new-rules software collectively, with obvious costs and coordination difficulties that implies.
The advantage of an approach like this is that new-software users can send coins to old wallets within the same transaction even as sub-sat outputs.