Beta is on cohost dot org

None of these are problems with FTP as a protocol. FTP is no more stateful than HTTP except in the sense that an FTP session maintains a certain amount of state within the session, which HTTP does too; to use HTTP effectively you also have to maintain significant amounts of state across sessions (tracking ETags, modification dates, cookies, etc). It is entirely possible to issue an RETR command with a fully-qualified pathname without issuing any CWD commands or any other path manipulation, which is exactly equivalent to GET. HTTP prior to HTTP/2 also suffers from significant problems FTP doesn't, most egregiously HOL-blocking, which FTP's socket-oriented behavior just doesn't suffer from at all, or at least doesn't have to with an appropriately capable combination of client and server software. It is also fully capable of restarting a transfer with the standard REST command which is simpler in operation than Range:. Finally, because FTP is a file-transfer protocol specifically, there's no worries about idempotency or anything period. It's reading and writing files.

At the end of the day, they're different protocols with different use-cases. HTTP has been extended to handle FTP's use case (with associated massive complexity to solve problems like HOL-blocking FTP just inherently doesn't have) along with just about everything else. It is not unreasonable to regret that a protocol specifically intended for file management specifically has been supplanted by one that just isn't and makes many of the use-cases harder and/or requiring special implementation that a capable FTP server would just provide automatically.