Indeed, Path.of was later introduced.

Conjecture: it was introduced for the sake of a consistent Foo.of style.

From the mailing list archive, this method was once called Path.get:

The main changes in are in Path and Paths in java.nio.file.

This patch copies the Paths.get() methods to static methods in Path.get() and modifies the former to call the latter respective methods. The Path specification is slightly cleaned up not to refer to Paths nor itself, e.g., “(see Path).” @implSpec annotations are added to Paths to indicate that the methods simply call their counterparts in Path.
...

This was later changed when Brian Goetz suggested it to be consistent with Foo.of:

Separately, Brian Goetz suggested off-list that it would be more consistent if these factory methods were named "of" so I assume the webrev will be updated to see how that looks.

Now to your last question: "In that case, it would be considered preferable on consistency/aesthetic grounds?"
In the initial mail Brian Burkhalter said that he updated all references to the new method in Path:

All source files in java.base are modified to change Paths.get() to Path.get() and to remove the import for Paths. ...

So I would therefore conclude that Path.of is indeed preferable to Paths.get.
Indeed, if you look at the Javadoc for Paths for Java 13 you will find this note:

API Note:
It is recommended to obtain a Path via the Path.of methods instead of via the get methods defined in this class as this class may be deprecated in a future release.

Yeah, I'd consider that a bug.

If you look at the code for WindowsFileSystem.getPath(String paramString, String... paramVarArgs), you'll find this code (jdk1.8.0_51, source of WindowsFileSystem not included, so this is from disassembler):

public final Path getPath(String paramString, String... paramVarArgs)
{
  String str1;
  if (paramVarArgs.length == 0) {
    str1 = paramString;
  } else {
    StringBuilder localStringBuilder = new StringBuilder();
    localStringBuilder.append(paramString);
    for (String str2 : paramVarArgs) {
      if (str2.length() > 0) {
        if (localStringBuilder.length() > 0)
          localStringBuilder.append('\\');
        localStringBuilder.append(str2);
      }
    }
    str1 = localStringBuilder.toString();
  }
  return WindowsPath.parse(this, str1);
}

The code adds \ between elements, even if preceding element already ends with a \, relying on a\\b to be compacted to a\b in the WindowsPath.parse() method.

So, get("\\", "x.txt") becomes \\x.txt, and two \ at the beginning is a UNC path, so parse() fails.

Suggestion, if you want to file a bug. Change code to:

      if (str2.length() > 0) {
        if (localStringBuilder.length() > 0) {
          char c = localStringBuilder.charAt(localStringBuilder.length() - 1);
          if (c != '\\' && c != '/')
            localStringBuilder.append('\\');
        }
        localStringBuilder.append(str2);
      }