I don’t see why this would be the case. If you measure from the time the last bit of the playlist is returned to the last bit of the video segment is pushed to the client, you’ll be able to estimate bandwidth accurately.
Based on my loose understanding of HTTP/2 server push and ALHLS, the sequence of events will be:
1. Client requests playlist for future media segment/"Part"
2. Server blocks (does not send response) until the segment is available
3. Server sends the playlist ("manifest") as the response body along with a push promise for the segment itself
The push then begins with the segment.
The push stream can presumably occur concurrently with the response body stream. So I don't think you can wait until every bit of the playlist comes in. Likewise, you can't use the playlist bits itself to gauge bandwidth because the server imposes latency by blocking.