Take DAI and xDAI for example. First, I feel that they are two different tokens, and should be rendered so in the wallet UI (although we can add some visual cue that they are connected, e.g. by linking one with another). The rationale is:
DAI and xDAI may not remain the same value. Both have a market. If xDAI's chain was found to have a security problem, xDAI will crash faster than DAI. DAI is an ERC20 token, meaning all the actions available to them (perhaps through inheriting an ERC20 tokenscript template) is available for DAI, not xDAI.
Now we recognise DAI and xDAI as two related but distinct tokens, the next question is if we should put them in the same Tokenscript.
The rationale behind putting them in the same Tokenscript is:
They are signed by the same entity and ultimately owe their existence to the same stewardship.
There are very similar actions. Let me elaborate:
Imaging when the user is buying something with DAI, but the DAI balance is insufficient, the Tokenscript for DAI might ask some xDAI to be converted. Let's call this "Conversion" action. For that, DAI Tokenscript needs to acquire permission to assess xDAI chain and proceed with the conversion.
The reverse might happen too when the user needs to checkout with xDAI and DAI balance isn't sufficient.
If it's possible to declare support for two tokens in one Tokenscript, the code would be sharable between (including CSS code) and permissions shared alike. If we don't do this, there might be inconsistency regarding "Conversion" action if DAI is using the latest Tokenscript and xDAI the earlier one.
Also, some tokens might be tight-knit for design reasons. Some projects experimented with having a twin-token structure for security tokens, where one token represents ownership and another right to claim the dividend. I personally think this is a case of overdesign - token ownership and the right to claim the dividend is called the same thing: "share" and it shouldn't be a problem to code both ownership and dividend login into one token. But let's say the designer of such twin token actually have a case where the two tokens need to separate. For example, one usually would borrow shares in order to short them, there might be the case that the lender wants to harvest the dividend until a certain date and the buyer agrees to obtain a share token without a dividend until then.
In general, we are not the guardian of good smart contract designs - tokenscript is often thought as an 'after product' of an already badly designed smart contract. I would assume whenever the requirements get complicated, the developer will decide "let's build a new token to do the new requirements". Having multi-token support in a single Tokenscript might be able to accommodate these inconsiderate designs.
The rationale behind one-token-per-Tokenscript is:
It's likely inevitable to invent stuff like inheritable Tokenscript or component Tokenscript, where one Tokenscript refer to another to borrow actions and such, which might be more suitable than having more than 1 tokens in one TokenScript.
It can be confusing when the user add Token A, Token B appears in their wallet with 0 balance which the user never intended to use. In our case, some users might only use xDAI and never for a moment thought about using DAI, and hate to see it hanging out there.