It's not just that Solana is fairly new; the entire way the chain works is “torment the programmer on behalf of chain speed”, and if one of those decisions causes trouble down the line, instead of taking a step back and going with the simple and elegant approach, they choose an ad-hoc patch that causes more trouble down the line.
One example of this is rent. You can store data in accounts. But if the balance of the account is lower than some amount (that depends on the size of the data), the entire account might disappear. Depending on the amount it might disappear immediately and you would find out, but if it is just below the threshold, the account could survive for years. So in any kind of transfer that involves an account that holds data, you need to be careful to check that its balance does not drop under the threshold. If you forget to check in just one place, your state may disappear.
Another example: program calls take a list of accounts. You need to manually serialize and deserialize your data into accounts. It's like writing a program in C where every function can only take an array of void* as arguments, and it is up to the caller to cast (serialize) all arguments to void* and pass them in the right order, and up to the callee to unpack the array again, cast back the pointers, and check that they are valid before dereferencing ... That's fine for a low-level target if a compiler could generate the tricky code for you. But on Solana it's your responsibility to do it manually, in Rust. Much of Rust's safety is useless here. (There exist eDSLs that alleviate much of this, but if you don't understand the underlying model, it is still easy to make a fatal mistake.)