The current Kibana style guide enforces API format compatible with elasticsearch API:
https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md#snake_case

Kibana uses snake_case for the entire API, just like Elasticsearch. All urls, paths, query string parameters, values, and bodies should be snake_case formatted.

The reality that:

• it's not always possible to follow this convention. For example, when passing around user input:

GET  /api/kibana/settings  
settings: {
  mySetting: { <—— registered by a plugin, Kibana shouldn't change the value
    userValue: ....
  },
}

• it's hard to enforce consistency across the Kibana. For example, a plugin provides data to other plugins via contract and API. As a result, the same data set has a different shape, depending on the way it's consumed. We have this problem with saved objects API [Core][WIP] SavedObjects v2 #40380

// pluginB
const data = pluginA.get();
data.someProperty.name

// or plugin B
const data = await fetch('/api/pluginA');
data.some_property.name

• It enforces data transformation between the client and server sides. As a result, client and server sides have to adopt the shape of data for both environments. It's not that bad, but all consumers have to adapt their code not to handle elasticsearch API as a source of truth anymore.

licensing.features.my_feature // received from elasticsearch
licensing.features.myFeature // across the whole Kibana
licensing.features.my_feature // when plugin interacts with elasticsearch directly

Open questions

• Do we still want to enforce elasticsearch API format?
• How to define when a plugin has to follow the convention?
• Should we follow the convention only in Kibana public API? How to define what set of API is public?