From my experience, "anemic DDD inspired architecture" is fairly common in enterprise .NET codebases. These do heavily use all kinds of value object, DTO and DTO-like objects with the logic that processes them being defined separately.
Unfortunately, most of them still suffer from premature and very unnecessary abstraction bloat. Luckily, the trend for terseness and minimalism is gaining more and more momentum each year, with just a single 100 LOC Program.cs microservices with asp.net core's minimal API no longer raising eyebrows and causing arguments in the teams as much as it used to. Extensive support for pattern matching, records, closures (since a long time ago) and other ways to define strict and terse data structures is also helping to preserve functional nature of this approach.
Note that JVM does not have structs and has a long way to go until project Valhalla becomes a reality. FWIW it has been less of an issue thanks to quite strong escape analysis as implemented by OpenJDK and GraalVM, but it does not afford the same guarantees and degree of control the structs do (not to mention lack of monomorphized struct generics as in Rust and .NET). In the "average codebase", structs in .NET have not been as popular historically, but with heavy focus on "close to the metal" features in both compiler optimizations and syntax, and increasing awareness of C# being a viable and effective systems programming language, this also is changing.