Recommendations for the BLE protocol

[Makinolo]

This is just my opinion, based on many years working in companies that build BLE hardware (Trainers, power meters, HR sensors, speed and cadence sensors...)

Button State Characteristic

The button ids should reflect physical buttons, not software actions. The software is the one that should be managing the button to action mappings. Hardware devices, more often than not, are very limited in resources, and you don't want to put extra burden on them.
So instead of having things like ERG Up or ERG down, which are actions, we should stick just to known button names found in gamepads for example, like the ones you use for Up Down Left Right or A, B, Y, X, LB, RB, LT and RT.
If a company wants to label their button as 'Z', they are free to do it, but they need to map it to the 'X' button.
Apart from that, the way most handlebar controllers identify button presses (kickr bike and Zwift controllers) is using a bitmap, which makes a lot of sense because it packs a lot of information in very few bytes. It's also faster to populate on the device side. With just 4 bytes you cover 32 buttons, which is more than enough for this use case. Then you have the analog buttons.
I'd suggest a hybrid solution to accomodate for the analog buttons, so you send first the 4 bytes with the digital button map, then 1 byte with the analog button map, followed by the analog values of all the analog buttons that are active in the analog bitmap.
There is no need for serialization overhead like protobuf because there are no more types of information contained in the notification.
So an example will be (hex values):

01 03 00 00 06 83 27

00000301 = 001100000001 Digital buttons 1, 9 and 10 are active
06 = 00000110 Analog buttons 2 and 3 are active
83 = Analog button 2 has a value of 131
27 = Analog button 3 has a value of 39

This format is very compact and will never overflow the MTU (4 + 1 + 8 = 13), even if we decide there is a need for 16 analog buttons, the maximum payload will be 4 + 2 + 16 = 22

App Information Characteristic

I would remove the App Information Characteristic. The hardware does not and should not care about what application is using it. It just has a purpose which is to send button presses and analog button values, and maybe vibrate or light some LEDs. One of the main goals shoul be to make life easier for device manufacturers to implement the protocol, because they are the most constrained part of the equation. You don't have the unlimited resources of a PC, a tablet or a phone.
If you want to maintain the feature "Device highlights or enables only supported buttons" or you want to show the current gear number in a screen on the device you should do it using the application via a specific Control Point command.

Control Point

The Haptic Feedback Characteristic should be instead a Control Point, like in many other services for other cycling devices. This way you can add more functionality in the future. The haptic feedback will be one of the multiple possible commands that can be sent to control the device. In the future you can add other features like LED handling, or even have separate vendor specific commands for terrain feel, like the one found in Tacx Neo trainers or controlling screen output for more advanced keypads.

Finally, it should be mentioned that the advertising packet should contain the 128 bit UUID of the service, in order to be able to identify it, and potentially (I don't know if iOS can read those) a service data field that informs about the basic features (i.e a 5 byte bitmap with the supported buttons, following the same bitmap used in button state char)