> It's annoying to jargonify, paper or not, because it doesn't help reduce the cognitive load of the reader and it makes the paper less accessible.

Actually, jargon does reduce cognitive load; that's why all specialized communities have it to make fine distinctions that are relevant in the community more concisely and precisely than less specialized language does.

No, not really. The intended audience for a paper like this is not a layman who needs a glossary, but a fellow expert fluent in the field's jargon.

Forget the "layman" elitist snobbery. There are people from adjacent fields and people in other fields who read such papers. Furthermore, that merely reinforces the "Latinization" of fields rather than making knowledge reasonably-accessible to all who wish to read it. In addition, prepress processing such a paper could easily add a glossary of term and/or hyperlinks mechanically.

It's not snobbery, but an acknowledgement that jargon exists for a reason, and that reason isn't to make the writing opaque to outsiders.

You're probably a software engineer. Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it? Are you going to explain the concept? No, you're going to write for your audience, and stuff like will get their way.

If you want to read infra-disciplinary writing, you need to be willing to do the work to familiarize yourself with the concepts and terms of the discipline that you don't understand, instead of expecting everyone, always, to offer close-at-hand definitions just in case. That latter expectation is only reasonable for writing targeted at a general audience.

> Are you going to write out REST (REpresentational State Transfer) in every design document you put up on your company wiki for your team that describes one, just in case a non software engineer wants to read it?

No, because that's not disseminated to a broader community. If it were, I'm going to link a standardized reference document that defines the terms, like they do in RFCs.

Edit: Actually, even with such an "internal" document, my preference would be to overexplain rather than underexplain, and define an acronym (or neologism I had learn myself recently) before using it. REST is a special case though, in that defining out the acronym doesn't actually help explain how people use it.

Nobody's going to take you by the hand every time you want to read something above you.

Have some humility.