I don't think "destructive" and "non-destructive" are even the right terms to use here. The API documentation refers to these as intermediate and terminal operations. Even an intermediate operation like peek consumes the stream it operates on and produces a new stream so I'm not sure what we're referring to here as being "not destroyed" or otherwise.
For example, you can't do this:
Because that would produce this exception:
java.lang.IllegalStateException: stream has already been operated upon or closed
Also, starting from Java 9 onwards, the line in question will not even produce any output (at least not when I ran it using different versions of the JDK on my Mac).
Starting from Java 9, the API documentation for Stream.count() has this note (emphasis on last line mine):
An implementation may choose to not execute the stream pipeline (either sequentially or in parallel) if it is capable of computing the count directly from the stream source. In such cases no source elements will be traversed and no intermediate operations will be evaluated. Behavioral parameters with side-effects, which are strongly discouraged except for harmless cases such as debugging, may be affected. For example, consider the following stream:
List<String> l = Arrays.asList("A", "B", "C", "D");
long count = l.stream().peek(System.out::println).count();
The number of elements covered by the stream source, a List, is known and the intermediate operation, peek, does not inject into or remove elements from the stream (as may be the case for flatMap or filter operations). Thus the count is the size of the List and there is no need to execute the pipeline and, as a side-effect, print out the list elements.