First, you should make a clear distinction that you are asking about Spliterator characteristics here and these depend on the source of the Stream; because there are also (CONCURRENT, UNORDERED and IDENTITY_FINISH for Collectors for example).
There is a comment in StreamOpFlag saying:
// The following Spliterator characteristics are not currently used but a
// gap in the bit set is deliberately retained to enable corresponding
// stream flags if//when required without modification to other flag values.
//
// 4, 0x00000100 NONNULL(4, ...
// 5, 0x00000400 IMMUTABLE(5, ...
// 6, 0x00001000 CONCURRENT(6, ...
// 7, 0x00004000 SUBSIZED(7, ...
As far as I understand these are not a direct 1 to 1 mapping with the ones from Spliterator, but still they are not used.
At the moment (and I've searched the jdk-8 and 9 sources), neither are leveraged - but still are reported by some implementations of Spliterators (Arrays report IMMUTABLE and ConcurrentHashMap reports NONNULL for example).
These flags could be used in the future on the other hand - if you know that a source can not contain null elements (NONNULL), obviously you can skip some null checks or define some state with a null. I can't think of any examples for CONCURRENT or IMMUTABLE, but there might be such.
For example under the current implementation for an UNORDERED and CONCURRENT collector (!= Spliterator properties), the combiner is not called when you do toConcurrentMap. For example:
Set.of("one", "two", "das", "dasda")
.stream()
.parallel()
.collect(Collectors.toConcurrentMap(Function.identity(), String::length));
will not call the combiner - since there is no need to.
Optimizations like these could be made for any of the 3 characteristics that you have mentioned. For example you can read this where StreamOpFlag.ORDERED has changed the result of findFirst in java 8 vs java 9