First of all, you should not worry about “duplicate a lot of the struct's fields into local variables”. The compiler is good at eliminating unnecessary memory copies, and even a few extra copies are likely to be unnoticeable unless you are writing a bulk data processing program that works on very large inputs.
Second, there are a lot of ways in which the cin >> C++ approach as you've written it is actually worse. For example, if the input is not a number (including if EOF is encountered), it will (if I remember correctly — it's been years since I touched C++ IO) fill the field with 0 leave the field uninitialized instead of immediately signaling an error.
If you're doing a lot of converting string input into fields, you should probably use a parsing library (if it's a custom syntax for each field) or a deserialization library (if it's a uniform syntax like JSON). Yes, it's more work up front, but it means you are more precisely specifying the behavior of your program and in particular its response to incorrect input.
(Of course, as written, this allocates more strings than necessary. That could be fixed by making read_line and read_and_parse methods of a struct which holds a buffer to be reused, handing it off and making a new one whenever an actual String is wanted.)
But you really shouldn't invent your own format. If you use something common like JSON, then it will be much easier for others to interact with whatever code/data you generate from the serialized representation.
This is simply not true. Others have already commented on the memory use fallacy. The C++ iostream methods actually behave worse than Rust's approximate equivalents. They sometimes silently ignore errors, sometimes they behave counter-intuitively (you can only read a string up to the first whitespace using >>), or downright lead to undefined behavior (if the int overload fails, it doesn't initialize the variable, so you end up reading am uninitialized value, which is instant UB).
The Rust code is not longer just for the sake of being longer. You should not assume that Rust is deliberately trying to be painful or hard to maintain. It's the opposite – Rust is being explicit, making the code easier to read and harder to write incorrectly.