In Substrate we make some assumptions and simplifications to keep the equations simple.
It does not take longer to read a larger value in general. This is due to the database backend chunking the data. There are jumps in the timing as described in the answer that I already linked above. There is a correlation between item size and access time, but its not linear.
Our observation was that most of the values that are currently being read/written on-chain are account data structs with 80 byte in them.
We then developed a benchmarking system which reads and writes the complete chain snapshot and collects the time that it takes for each value. The usage is documented here.
The average results are calculated and used as constants for reading or writing a single value.
This has the advantage of being very simple to calculate. You have to keep in mind that every formula for calculating the weight needs to be really cheap, a constant is therefore perfect.
The downside is that it needs to be regularly updated to represent the average read and write weight. We currently add 15% to the calculated constants to adjust for a lag of updating them.
If you want to optimize the weight of your Pallet, you have to find the sweet spot between number of storage accesses and item size.
The item size is not important right now, but will be important once Weights V2 hits.
This effectively prevents you from putting all the data in one huge storage item because of the huge PoV size this would inflict.