Frankly I don't see much motivation to have this allowed, but if there is some I'd guess it would not harm anything to add this to spec.

One use case could be on the interface of P4 and CPP -- i.e. this gives the programmer ability to compare (at compile time) a string coming from preprocessor with some pre-defined values and have the result be a valid P4 value. While this can always be done using ifdefs or by changing the macro defines, using this on strings may be a little cleaner.

const bool isFoo = DEVICE == "foo";

instead of

#if DEVICE == "foo"
const bool isFoo = true;
#else
const bool isFoo = false;
#endif

or

#if DEVICE_FOO
const bool isFoo = true;
#else
const bool isFoo = false;
#endif

So this might be useful, although I'm not sure still. On the other hand I would tend towards allowing it (with spec change) as it would make string more like a regular primitive type (there is already match_kind and int that can be compared at compile time, can have variables, and int even has a lot of other operations, so I don't really see why string can't be allowed similar levels of compile-time existence). I'll think about it a bit more and then I guess we will discuss it in P4 LDWG in September.

p4lang/p4-spec#1306 is the related specification issue.