Short answer: it isn't intentional and there's nothing "mystical" going on – you're seeing race conditions inside a very large pool.

A pool is not one machine. Foundry/ViaBTC have many stratum servers, proxies and miners spread across the world. When one of their miners finds a block at height H, the pool has to build a new template whose prev-hash is that block and push a clean job to all connected miners so they stop working on the old tip.

Neither step is instantaneous. It takes tens–hundreds of milliseconds to build/distribute a new job, and some miners/proxies are a few hundred ms or even seconds away over the network. During that window a different miner from the same pool can still be hashing on the old job and may find another block. Now the pool has two blocks at the same height. Whichever propagates better wins; the other becomes an orphan. From the outside this looks like "the pool forked itself".

Why you didn't always see it on your node? Probably because very short-lived blocks get eclipsed before they reach all peers. You only see the block that reached you first; fork.observer aggregates data from many nodes and can show blocks that your node never received. In your log you have two UpdateTip lines for the same height with different hashes – that's exactly a one-block reorg caused by two competing blocks (both tagged to the same pool).

Pools can't really totally prevent this, they can only reduce the probability by doing things like:
Push "clean_jobs=true" immediately after a new tip, keep very fast block propagation (FIBRE, compact blocks, good peering), lower template refresh latency and avoid slow stratum/proxy setups, Stratum V2 (job negotiation) helps, but still can't make propagation instantaneous.

As long as pools are globally distributed and block propagation isn't instantaneous, occasional self-forks are unavoidable. Your observations for Foundry/ViaBTC are consistent with that.