Datasheet is typically written by a team of engineers.
Design Engineer writes how the IC works, guided by the project definition (an internal, company confidential document). Those confidential in-house product specifications always include diagrams of the relevant interface bus (such as SPI or MIPI whatever), because that's the document that guides the actual IC development. As a result, this information (as interpreted by the design team) is included in the datasheet.
Test Engineer writes how the IC is tested, especially the big Electrical Characteristics table -- these Minimum / Maximum values are what determines whether an individual IC is shipped or scrapped.
Applications Engineer or Product Engineer tests out the IC from the outside, as a customer would, and also collects the typical performance data that appears in the various "scope shots" and other plots. The Apps team also does bench testing of the IC against what the datasheet claims. If the IC does not perform to spec, then the Apps team can reject the IC design. The idea is that the datasheet should show the customer everything relevant to what the part actually does.
You mention I2C specifically; note that the I2C standard itself has gone through several revisions, first increasing the speed, then adding more complexity to support even more speed. And subsequently I2C was used as the basis for the SMBus and PMBus standards. So it's very risky for a datasheet to just reference "the standard", since the standard can change. If the vendor released an IC that was compatible with I2C (version 1.0) and then turned out not to be compatible with I2C version 2.0, then that vendor has a serious legal liability if they did not further capture the actual guaranteed performance in their own datasheet.
