I'd chime in on a somewhat lesser known part of networks that in practice the real determinant of performance: congestion control. The effects can be on the scale of an order of magnitude or two. The problem of how decentralised nodes in a network can use finite network resources optimally is fundamentally unsolvable (proved by Jaffe, intuitively nodes never have perfect information). Most congestion control algos use a congestion window (the amount of data in-flight) to limit themselves, this window is divided at a packet loss (aka congestion event) and increased when a successful round trip is made (in modern algorithms logarithmically if below a steady state assumption, cubic if above). There's a general consensus that these algorithms perform extremely poorly on long, fat networks because size of window growth depends on the round trip. Put another way, increasing bandwidth far from directly improves throughput. Latency in worst case is limited by the speed of light, and is in the order of the 150ms to 250ms range in the time it takes for light to travel alone. So there are fundamental limits on the latency that Starlink can provide.

Some back of the envelop calculations = it takes about 7ms in extra latency to travel up and down to the satellite vertically on a round trip, and modeling fiber optic vs starlink as two spheres of different radii starlink will take ~16% more time. Performance will be also extremely affected by the reliability of the medium ie packet loss from errors transmitting through the atmosphere vs fiber optic. Most congestion controls believe latency and packet loss comes from congestion and will aggressively back off. When I tested this on my own 866Mbps WiFi network with iperf and linux qc, with a 100ms latency and 1% packet loss my throughput was 1.86Mbps. At 5ms latency and 0.01% packet loss it was 58Mbps.