Jira’s rate limiting implementation is optimised towards getting the most value out of Atlassian’s server resources whilst protecting the user experience, but it not “app friendly” because it doesn’t provide apps with any certainty about limits and, as you point out, doesn’t necessarily return a Retry-After header with 429 responses. The Jira team are currently making some improvements to this, but here are responses to your questions as per the current implementation:
OAuth REST API requests are subject to the same rules.
Rate limits are shared across users and apps. The implementation does not have the concept of quotas per user or consumer. As such, there is no way to determine that another app or user is straining the API and causing the rate limits.
The implementation is configurable, but only by SREs to keep everything running. There’s no ability for a customer to modify their rate limit settings.