This document attempts to capture useful patterns and warn about subtle gotchas when it comes to designing and evolving schemas for long-term serialized data. It is not intended as a guide for how to best represent a particular dataset or process.
I agree that specifying types is better than free form strings with known values defined outside the IDL. However there are some pitfalls to using enums (in particular in thrift but I guess in other places). The downside is adding a value to an enum is an incompatible change that will break readers using an older version of the IDL. Deserializing a record that contains an unknown enum throws an exception (again, this is true with thrift).
An alternative is to use Unions instead of enums. You can see a union as a more general form of the enum. The advantage is it's a cleaner way of defining fields that exist only if the enum is a certain type (ever done something like this ? if (record.getState() == SUCCESS) { doSomething(record.getResult()) }). If you encounter an unknown value with an old version of the IDL for the union then it returns null and it doesn't affect code that is doing something only for some of the known values. In the same example above if you add more precise states like FAILURE and ABORT, your code still works. adding types to a union is not a breaking change, adding values to an enum is.