File is from java.io, while Path is from java.nio (New I/O), which is a complete rethink of how I/O works, going from a "steam of bytes" paradigm to one of buffers and channels, enabling non-blocking I/O and DMA transfers.
In particular, File conflates several concepts: a filesystem, a path to a file in that filesystem, and a file's contents as byte streams. Path only represents a path, you need to use a FileSystem object to read from a file at that path, and you get a Channel for reading/writing that is used to fill a Buffer.
However, File does not need to be substituted. java.io is not deprecated nor is it slated for deprecation, and there are easy ways to convert from File to Path and vice-versa.
But nothing in File is tied to "stream of bytes", it's really just an immutable ID that may or may not point at an entity in a file system. What it adds is operating on filesystem attributs in a best effort WORA way, which leaves room for improvement (nio allows decidedly non-WORA digging into details I think?), but is very valuable to have because it satisfies most use cases in a more convenient way.
As you said, File won't go away. But it really does not feel right to not have File implement Path, or perhaps a subset of Path that would be good enough for all those use cases where something outside the identifier acts on the identified entity. Every .toFile() and .toPath() is a little defeat in API evolution, and there are a lot of those. Do they consider addition of an new interface, to an existing class a break of compatibility? On 17 windows (that's what I happen to be looking at), a chain of toPath/toFile/toPath won't even give you a symmetrically bound pair of immutables, toPath is memoized but toFile is not. Should not have been too hard keeping a provenience reference on the other side, or have memoization on both sides?
In particular, File conflates several concepts: a filesystem, a path to a file in that filesystem, and a file's contents as byte streams. Path only represents a path, you need to use a FileSystem object to read from a file at that path, and you get a Channel for reading/writing that is used to fill a Buffer.
However, File does not need to be substituted. java.io is not deprecated nor is it slated for deprecation, and there are easy ways to convert from File to Path and vice-versa.