Why not a synthetic wrapper or a basket of assets?
Within DeFi there are a number of models of how a synthetic asset should be minted or backed by the assets it's meant to represent. They can take form in various ways however the most common within LSDfi are as follows:
These are 1:1 representations of deposited assets, for example, if there's an asset that serves as an index of underlying LSTs, the user would deposit “N” LSTs and receive “N” Index tokens. The protocol would then collect the staking rewards of the underlying staked ETH and then pay these to Index holders, after taking a protocol fee.
While very simple, with a convenient user experience - there are unfortunately downsides to diversifying across various assets. The protocol either has to prioritize diversity of assets, that is, integrating as many LSTs as possible so users can have a true average of staking yield across the ecosystem - or focus on the security of the synthetic as a failure of any of the underlying LSTs can lead to a failure of the entire wrapper.
Of course, wtapETH is a wrapped asset - however of tapETH itself, so there are no third parties, nor an extensive list of bridged and wrapped versions.
Since there aren't any meaningful pricing mechanisms - the value of the Index token is at the mercy of market behavior. While this isn't the largest concern, we have experienced many depegging and mispricing of wrapped assets, with excessive amounts of time before they return to parity.
CRV wrappers have notoriously been off peg when the market becomes bearish, driving demand away, and making it difficult to return to parity until sentiment improves.
Multi-asset Liquidity Pools
This is a far more popular model, with it effectively constructed as a 3Pool (albeit with more assets), most commonly with ETH and then a handful of market leaders such as stETH, rETH and frxETH. A user simply deposits any supported asset and receives an equal amount of secondary-LST in return e.g. depositing 1 ETH, and 2 stETH into XYZ protocol (that has ETH, stETH, frxETH and rETH within the pool) would receive 3 LSTxyz in return.
These protocols pay out underlying staking yield, as well as fees generated by the swaps that take place between the assets within the liquidity pool. While more complex, this still maintains simplicity and an intuitive user experience, however has a number of drawbacks.
The most significant downside to this model is by far, pricing stability. Every asset within the pool is at the mercy of the other assets, since each additional asset carries with it a whole host of variables such as market sentiment, security concerns and so on. As a result, the risk is compounded and then shared, such that should any asset within the pool become depegged in the wider market, it would immediately translate to the protocol and lead to an "undercollateralized" pool (i.e. the amount of pegged LSTxyz in the ecosystem would be more than the value of the assets within the pool).
Because all the assets exist within the same pool, there are inevitably knock-on effects to the other assets which can lead to reduced stability and confidence and makes it excessively hard to recover due to no obvious way to arbitrage the mispricing by users. While not the most significant concern for regular users, it will make it difficult to see significant use of these kinds of assets within primitives that require pricing stability e.g. leveraged applications, lending and so on.
Another side-effect of having all the assets within a single pool, is the fact that integrating and supporting more assets becomes more and more difficult, due to the fact that new entries have to have pricing curves with all the other assets and weightings taken into account. This is of course a manageable obstacle, however the maths becomes increasingly complex and untested (in terms of market activity), which ironically increases the risk profile, despite the underlying composition being more diversified.
tapETH chooses an individual pool mechanism because multi assets in the same pool will face price stability issues and be hard to integrate more.