Oh boy, I have a strong opinion about this!

When you have a bunch of systems that talk to each other by sending structs on the wire or saving them to disk, you really need a struct definition language that looks like Google's Protocol Buffers, and generate code from that. Here's the key feature that sets it apart from your language's native record system:

You can take a struct definition, add some fields, remove some others, recompile the program that sits on one side of an API, leave the program on the other side unchanged, and things will still work. Or you can deserialize some structs that were serialized with the old definition, and things will still work. It's not a coincidence, in fact it's a guarantee that our code relies on every day. It's achieved by assigning a numeric "tag" to each field in a struct, and never reusing old tags when updating the struct definition. This is called versioning and it's absolutely indispensable.

This means you cannot have non-nullable fields. All fields must use the moral equivalent of Maybe or Nullable. (Protocol buffers do have required fields, but people quickly figured out from experience that they cause horrible problems, and now they are frowned upon.)

Protocol buffers are an amazing idea. Sure, if you have something simple like a point with X and Y coordinates, you might be better off your language's native pair or record facility. But once you have a data struct with five or six fields, I can almost guarantee that it will keep changing, that it will need to go on the disk or wire someday, and that it'll be better off as a proto rather than your language's native thing. The generated code of protos comes with tons of useful methods for introspection, serialization, versioning, etc that you will almost certainly need.

To cover the static vs dynamic angle, you can generate code in multiple languages from the same proto definition (which will be serialization compatible of course), and in each language it will be as strongly typed as the language allows. I do feel slightly more comfortable using protos in a language with static checking, but it makes a minuscule difference compared to the choice of using protos in the first place.