Structs and naked fields will ease interoperability with some not managed APIs. Often you will find that the low level API wants to access the values by reference, which is good for performance (as we avoid an unnecessary copy). Using properties is an obstacle to that, and often times the wrapper libraries will do copies for ease of use, and sometimes for security.
Because of that, you will often get better performance having vector and matrix types that do not have properties but naked fields.
Best practices are not creating in vaccum. Despite some cargo cult, in general best practices are there for a good reason.
In this case, we have a couple:
A property allows you to change the implementation without changing the client code (on a binary level, it is possible to change a field to a property without changing the client code on a source level, however it will compile to something different after the change). That means, that by using a property from the start, the code that references yours will not have to be recompiled just to change what the property does internally.
If not all the possible values of the fields of your type are valid states, then you do not want to expose them to client code that code modify it. Thus, if some combinations of values are invalid, you want to keep the fields private (or internal).
I have been saying client code. That means code that calls into yours. If you are not making a library (or even making library but using internal instead of public), you can usually get away with it and some good discipline. In that situation the best practice of using properties is there to prevent you from shooting yourself in the foot. Furthermore, it is much easier to reason about code if you can see all the places where a field can change in a single file, instead of having to worry on whatever or not it is being modified somewhere else. In fact, properties are also good to put breakpoints when you are figuring out what went wrong.
Yes, there is value is seeing what is being done int industry. However, do you have a motivation to go against the best practices? or are you just going against the best practices – making the code harder to reason about – just because somebody else did it? Ah, by the way, "others do it" is how you start a cargo cult.
So... Is your game running slow? You are better of devoting time to figure out the bottleneck and fixing that, instead of speculating what could it be. You can rest assured that the compiler will do plenty of optimizations, because of that, chances are you are looking at the wrong problem.
On the flip side, if you are deciding what to do to begin with, you should worry about what algorithms and data structures first, instead of worrying about smaller details such as fields vs properties.
Finally, do you earn something by going against best practices?
For the particulars of you case (Unity and Mono for Android), does Unity takes values by reference? If it doesn't, it will copy the values anyway, no performance gain there.
If it does, if you are passing this data to an API that takes ref. Does it make sense to make the field public, or you could make the type able to call the API directly?
Yes, of course, there could be optimizations that you could do by using structs with naked fields. For example, you access them with
Span<T>, or similar. They are also compact on memory, making them easy to serialize to send over the network or put in permanent storage (and yes those are copies).
Now, have you picked the right algorithms and structures, if they turn out to be a bottleneck, then you decide what is the best way to fix it... that could be structs with naked fields or not. You will be able to worry about that if and when it happens. Meanwhile you can worry about more important matters such as making a good or fun game worth playing.