Records and primitive classes (the new name for value types) have a lot in common — they are implicitly final and shallowly immutable. So it is understandable that the two might be seen as the same thing. In reality, they are different, and there is room for both of them to co-exist, but they can also work together.
Both of these new kinds of classes involve some sort of restriction, in exchange for certain benefits. (Just like enum, where you give up control over instantiation, and are rewarded with a more streamlined declaration, support in switch, etc.)
A record requires you to give up on extension, mutability, and the ability to decouple the representation from the API. In return, you get implementations of constructors, accessors, equals, hashCode, and more.
A primitive class requires you to give up on identity, which includes giving up on extension and mutability, as well as some other things (e.g., synchronization). In return, you get a different set of benefits — flattened representation, optimized calling sequences, and state-based equals and hashCode.
If you are willing to make both compromises, you can get both sets of benefits — this would be a primitive record. There are lots of use cases for primitive records, so classes that are records today could be primitive records tomorrow, and would just get faster.
But, we don’t want to force all records to be primitive or for all primitives to be records. There are primitive classes that want to use encapsulation, and records that want identity (so they can organize into trees or graphs), and this is fine.