From the documentation at: https://golang.org/pkg/net/http/#ServeContent:

ServeContent replies to the request using the content in the provided ReadSeeker.
The main benefit of ServeContent over io.Copy is that it handles Range requests
properly, sets the MIME type, and handles If-Modified-Since requests.

Echo does not support this functionality.
We can see echo.Context.File() calls context.ServeContent:
https://github.com/labstack/echo/blob/master/context.go#L381
Which does a basic io.Copy() to send the entire file to the user:
https://github.com/labstack/echo/blob/master/context.go#L439

So in the current implementation when you call echo.Context.File there's no chance that anything will be resumed if a download had cut off previously and a browser attempts to resume it using the HTTP Range header which isn't considered by this code. It simply sends the entire file every time.

The documentation surrounding HTTP Range is here: https://tools.ietf.org/html/rfc7233

One more advantage the standard library has over this is that the Content-Size header is also set which is not the case in the echo code.

Ideally we'd be able to completely defer to the standard libraries http.ServeContent method.