You've kind of alluded to these in your original post, @ggalmazor, but to make sure we're on the same page, these are the user-facing performance issues I see as priorities:
- Loading forms with many questions can take a long time
- Saving values in forms with many expressions that tie fields together can take a long time
- XPath queries can take a long time
- Loading forms with large secondary instances can take a long time
Hopefully we can agree on a list of high-level problems like the ones above and target those by starting with exactly what you suggest:
There are more good forms to consider at Share your BIGGEST or slowest form and win a badge!. As a step even before that, how about starting with synthetic forms that have particular characteristics? For example, I would be interested to have benchmarks for first load, cache load, and saving values into a form with 1000 simple questions (e.g. many_questions_1000). These could be used as a baseline to compare real forms against.
Hopefully we could then actually say with confidence, for example, how performance and number of questions in a form are related. Linearly? Not at all, it's only the number of relations between fields that matter? Etc. That will at least help us better communicate with users about the implications of form design decisions and hopefully also start the process of identifying areas for improvement.
It's a core part of Java as of Java 9 so that makes it clear to me that it's the way to go. 
Crucially, we can trust it really does properly hide away JVM optimizations that can make reliable, trustworthy timing data so hard to get.
Yes. Maybe even with Collect as the client? Ultimately, that's where users are feeling the pain. And there's certainly at least some overhead at that level.
This might be nice to have but I don't think it's a priority. As long as there's a consistent way to get performance information, we can make sure it's something reviewers do when there are questions about the performance implications of a change.