Hey, thanks for kicking off the discussion! The ERC is still a draft so you are indeed not too late. Here are my takes:
Intent
The primary intent of the standard is to be practical and immediately useful rather than abstract and prescriptive. We hand application developers an easy, safe oracle adapter standard together with Euler’s library of well-audited compliant adapters that cover 99% of use cases. This saves them time and money, while making their dapps a bit more secure. It would be great if incumbent oracle providers supported ERC-7726 in their primary data feed contracts, however this is a huge ask with a lot of friction.
To highlight the impact let’s examine the status quo (I can only speak about lending protocols). Due to historical reasons the de-facto oracle adapter standard is Chainlink’s AggregatorV3Interface. Once you enshrine this interface in your consuming application it is almost permanent; nobody in their right mind would upgrade a mission-critical component in production for a quality-of-life improvement. The effect is that a new provider that wants to compete is almost required to serve prices through AggregatorV3Interface (see RedStone Push, Chronicle, API3 among others).
The interface is ideal for Chainlink price feeds but subpar as a general future-proof oracle adapter interface. It holds baggage for backwards compatibility, requires superflous functionality, and is not composable (returns a fixed-point price rather than an amount quote). This makes for a few gotchas when consuming a non-Chainlink provider that shoehorns the interface: take a look at this security note as an example:
api3dao/migrate-from-chainlink-to-api3?tab=readme-ov-file#when-to-useapi3partialaggregatorv2v3interface
Timestamps
With regard to timestamp, I agree they are very important for assessing staleness. ERC-7726 requires that any validation (including timestamp) be performed inside the oracle adapter without leaking that anywhere: see this example.
euler-xyz/euler-price-oracle/blob/master/src/adapter/chainlink/ChainlinkOracle.sol#L63-L74
Just because you nerdsniped me I’m going to share another observation about timestamps. While the providers you mentioned all return a timestamp, the semantics of it is not the same. Chainlink’s timestamp is the arrival timestamp of the price update, i.e. the timestamp of the block where the update transaction was included. Pyth’s timestamp on the other hand is the observation timestamp, i.e. the windowed timestamp when the price was queried (a third type of timestamp is the price of an AMM-sourced TWAP oracle). The difference in practice is small, however there are circumstances (L2 sequencer is down for example) where not appreciating the semantics may be catastrophic.
Finally I want to disagree that timestamps are ubiquitous. If you want to consume the exchange rate of an LST you can query the project’s Consensus Layer oracle. This is usually a committee that does the accounting and updates the exchange rate at regular intervals. In this case timestamps may not written to the chain. And exchange rate oracles are pretty popular currently so this would make them a major exception to the rule.
Finally some price sources do not have a timestamp. If you’re returning a 1:1 fixed price there is no intrinsic timestamp to that adapter. Yes, you could return block.timestamp as a synthetic timestamp but that would be superfluous.