I know that each developer used the structure as Guid. However, I also see the fact that many developers create them in different ways. So, looking ahead, I'll say that both ways don't differ if considering making a new Guid from the string. If you look at the benchmarks, you'll see they have the same performance.

|       Method |     Mean |    Error |   StdDev | Allocated |
|------------- |---------:|---------:|---------:|----------:|
|   GetNewGuid | 29.19 ns | 0.251 ns | 0.235 ns |         - |
| GetParseGuid | 29.69 ns | 0.304 ns | 0.284 ns |         - |

For this reason, why did Microsoft invent the method Guid.Parse(), if you can use a constructor? I'll try to explain. The fact is that the constructor has six overloads. So you tend to use a constructor only with the strings, something like that:

new Guid("1B701A0A-D548-48E0-A0B5-F4624A83C38E");

However, I, with ease, can change this code and pass other parameters. And we'll receive this:

new Guid(1,2,3, new byte[]{0,1,2,3,4,5,6,7})

Of course, I do not think that someone will definitely change the parameters, but there is such a possibility. Since software development should hide the possibility of changing the code as much as possible, initialization with a constructor is not suitable for this idea. For this reason, there is the Guid.Parse(). This method usually takes only a string, has an optional culture-formatting parameter, and requires at least one parameter. However, as with a constructor, it may take no parameters and produce a default Guid. So it'll be something like this:

Guid.Parse("1B701A0A-D548-48E0-A0B5-F4624A83C38E", CultureInfo.InvariantCulture)

That's why I think the best way is to create a new Guid from a string. However, both methods are correct. With the only difference that Guid.Parse() is more suitable for work with the strings. The only difference is that Guid.Parse() is more suitable for working with strings.
For more information, you can see here.