Core library maintainers should be encouraged to use assert,
so that more bugs could be found running tests with -esa.
However, library maintainers are reluctant to do this because of
lingering Fear Uncertainty and Doubt that their performance-critical
code will run a little slower.

One concern is the inlining threshold, which is based on the size of
methods based on bytecode, which does not take into account code which 
is dead because it is conditional on a static final boolean.

So library code maintainers fiddle with various inlining and "out"-lining
strategies for static final booleans and asserts.

private static final boolean flag = ....;

void m() { if (flag} { ... } else { ... } }
or
void m1() { ... } void m2() { ... } void m() { if (flag) m1(); else m2(); }

A compiler-maintainer-oriented way of expressing this request is:
before any method's size as measured in bytecodes is used
for inlining heuristics, make sure a dead-code elimination pass
that takes final static booleans (or ints?) into account should
be used to derive a better size for using with inlining heuristics.

Another issue is the startup cost for computing asserts.
Each class containing an assert runs a bit of code to initialize the
synthetic static final boolean via a jni call.  If every class in the JDK
did this, this cost might be significant.  Even if the cost is small, the
cost is borne by every Java program that uses those classes, which, in the
case of some core classes, means every Java program period.