Investing into much more complex browser extensions such as eg QUIC has necessarily even lower usage. Basically, this rationale for removing FTP support is made up/self-delusional when the reality is that Chrome devs want to drop "legacy" features to focus on others.

ProFTPD, pure-ftpd, and vsftpd are all active projects that are shipped with every major Linux distro. It has first class support on Windows through IIS. Every platform has native clients for it.

FTP is guilty of not being cool anymore but letting it die completely seems like such a waste. FTP could be the already widely-supported solution to the send a file between two devices problem that has a million bespoke solutions. Oh well.

It really couldn't. It has no discovery, no active identity validation story, issues with NAT traversal, relies on filesystem abstraction, ... In sending a file between two devices the actual file sending is the most trivial part and the only part that FTP can do (in the old and clunky let's-split-control-and-data way). We deserve better.

The advantage that FTP has is ubiquitous and broad device support. FTP can provide the transport and authentication for a huge variety of devices and provide an instant user story of how to connect with older devices. Discovery and NAT traversal are external to the transport protocol anyway and would be just supporting _ftp._tcp records and the normal TURN/STUN servers.

FTP has actual stateful filesystem traversal commands. PWD / CWD / CDUP / ... . Of course it can be faked, but why bother?

I understood devices in the comment as personal devices for end users rather than servers. In that case discovery is really not external. Same with NAT - it's a difference between "kind of works sometimes" and "is designed to work with it". See Skype's initial success. Or how SIP documents NAT behaviour extensively https://tools.ietf.org/html/rfc6314