|If constexpr is for performance elevating, why not using it always? For instance, for all functions?!|
It is a bit more specific to qualify that constexpr is able to improve performing by performing calculation at compile time. From a user's perspective executing the resulting application, nothing is faster than what was already done before they even started the application.
It is also a descriptive decoration, much like an adjective.
As such, it shouldn't be used everywhere that the description does not apply. A function which can't possibly be evaluated at compile time should not be declared constexpr on the hope somehow it might be at some point, or that the declaration as constexpr would be harmless if it were not. The human reader would, unless some careful reading were applied, assume that a constexpr declaration has at least some chance of being evaluated at compile time, and that it was the intent of the author to take advantage of that. If the underlying function can't possibly be constexpr, it would be like applying the adjective "happy" to everything being said, even when it didn't apply.
In some ways one might say that the constexpr keyword isn't even necessary from the viewpoint of optimization. Most good optimizers recognize when expressions happen to evaluate at compile time and avoid emitting run-time code in such situations anyway.
However, it's use allows the compiler to "recognize" the author's intent to rely upon some expression forms which are potentially evaluated a compile time, and write code that can make that assumption where appropriate. Optimizers themselves are far removed from what we write, and should be, but here we have a keyword which brings such a concept within reach of the code consuming a constexpr, giving rise to author controlled (or at least requested) compile time computation by intent.
In some ways this mimics the reality behind "inline", another "performance elevating" keyword, which has an otherwise not to well recognized meaning. The "inline" keyword is almost unnecessary from the viewpoint of optimization. It is often even ignored by the compiler, giving rise to frustration when this is recognized. However, the "inline" keyword is as much about informing the linker that duplicate functions are to be expected (and warnings not issued) because the function was written in a header "inline" and not explicitly compartmentalized into a translation unit (CPP file). That is it's primary purpose, not the hint that the emitted machine code should skip a function call.
The optimizer will "skip" function calls by inline code whenever it is possible (and configured to do so), with or without the "inline" keyword.
This is much the same with respect to your thinking about sprinkling "constexpr" everywhere - it really wouldn't elevate performance any more than good optimizers do anyway. Like the "inline" keyword informing the linker to ignore the duplicate appearances of functions in the build, the "constexpr" keyword is less about the optimized output and more about whether or not what we write can use an expression with compile time evaluation within the knowledge of the human author, and the features of the language - a stage far ahead of and before optimization of the final product.