Based on my tests with a few different Oracle and OpenJDK implementations, it seems that Arrays.equals(char[], char[]) is somehow about 8 times fas
Because for chars, SSE3 and 4.1/4.2 are both extremely good at checking state change. The JVM-generated code for char manipulation code is more tuned because that's what Java gets used a lot for in web apps and such. Java is awful at optimizing for other kinds of data. That's just the nature of the beast.
This same behaviour is observable in Scala and GoSu as well. The bulk of information in transit these days is in text form, so unless you modify your JVM, it's tuned for text. And, as Marco mentioned, it is an intrinsic C function underneath, meaning it directly maps to high-performance vectorized instructions like SSE4.x or even AVX2 if the standard JVM has been improved that much.
http://blog.synopse.info/post/2015/06/30/Faster-String-process-using-SSE-4.2-Text-Processing-Instructions-STTNI
http://www.tomshardware.com/reviews/Intel-i7-nehalem-cpu,2041-7.html
Seriously, SSE4.x does not treat chars and bytes as equivalent data types, which is why text analysis is faster. Furthermore, for 8-bit integral, comparisons the instructions didn't exist until AVX2.