Self Governed Super Token

Super Tokens are by default upgradable, with the default upgrade admin being Superfluid governance.
While it's possible to deploy non-upgradable Super Tokens, that is currently not recommended. The reason is that the protocol is still evolving, and a Super Token stuck with the current logic risks to being unable to make full use of future framework versions. This could manifest itself for example by partial incompatibility with periphery like the canonical Superfluid Dapp.

Mechanism

It is possible to deploy a Super Token which is upgradable and using the canonical logic, but with the upgrade admin set to an account specified at deployment time.
For an ERC20 wrapper, this can be achieved by invoking SuperTokenFactory.createERC20Wrapper() with an additional address argument (the function is overloaded).
For a Pure Super Token, this can be achieved by initializing the Super Token contract with SuperToken.initializeWithAdmin().

If an admin address is provided at deploy time, it is written to the storage slot defined by EIP-1967.
In SuperToken.updateCode(), the modifier onlyAdmin is used to determine if an admin is set. If not, the host contract is used as fallback admin (through a code path only Superfluid governance can call).

Purpose

Setting an admin account gives the deployer more control over a Super Token.
First of all, it disables "auto-update" in the sense that Superfluid governance cannot update the Super Token logic anymore.
On the flip side that however means the deployer needs to take care about updates if necessary and wanted.

Doing this is recommended if you want the option to later switch to a custom logic contract containing additional functionality or modified behaviour.
If the goal is additional functionality, a not-yet available feature may be useful, see https://github.com/superfluid-finance/protocol-monorepo/pull/1700. If you want this, please contact the dev team.

It's important to understand that setting an admin doesn't take away all control from Superfluid governance.
As long as the Super Token logic gives privileged access to upgradable framework contracts - most importantly, to the host and agreement contracts - that implies that Superfluid governance ultimately also has control over the state (storage) of the token.
The Super Token upgrade admin does however have the optionality to secede from the framework, should the wish arise. It basically allows to rage quit and strip Superfluid governance of any privileged access, making a Super Token contract fully independent.
Currently it's not possible to do this without becoming incompatible with the wider Superfluid ecosystem (subgraph, Dapp etc), but that may change in the future.