Sadly vJASS abstracts a lot of what is happening "under the hood".
A struct in vJASS is nothing more than an index in a group of parallel arrays. When you pass a struct between functions what should happen (not what happens but should happen) is it passes by argument every single member of the struct (each parallel array becomes an argument). If you want to pass the struct reference (the index inside the parallel arrays that the particular struct instance is located at) a special keyword should be used. This would mirror C++ objects and is completely logical.
Instead when you pass a struct in vJASS it automatically passes the reference without giving you the option to pass by value (or copy). This means that what is actually being passed is an integer, can be treated as an integer and can be manipulated like an integer. It is completely valid to add 1 to a struct in vJASS although it will now represent a different instance, potentially not allocated (may cause errors).
Equally well vJASS lacks an array allocator for structs, which would map a continuous block of indices as used and return the base index. This would be the one time where mathematical operations on dynamic struct references would be useful. Instead you are given the rather hacky "extends array" syntax which I am not entirely sure what it means but basically allows you to skip allocation and treat the struct as an array directly (although syntax is more complex, it actually is giving you lower level access to the feature).
One could say the entire struct concept is flawed. Like in C++ a struct should just define a collection data elements. The actual implementation (where the parallel elements is stored) should be up to the user to declare. If they specifically request new then a struct heap should be generated for dynamic allocation with new array being an extension. If they declare a struct array it should give them direct access to a struct heap (in parallel to the allocation heap if any). Finally they should be able to declare a struct variable which just statically links to parallel non-array globals. This should also apply to locals but obviously the use case is less common. Only when using dynamically allocated structs should you deal with a struct reference. The biggest advantage of this is that it would allow singleton structs to not allocate arrays and access variables directly (not via index). It could also allow various forms of allocation management ranging from hashtables to "you decide" that a user could specify as compiler hints.