Example demo: https://demos.telerik.com/aspnet-ajax/combobox/examples/overview/defaultcs.aspx
And here's what JAWS sees:
Note the extra unlabeled "Button" following every combo box. This is confusing to the reader. They have no way to know that it is associated with the preceding field.
Additionally, I've noted that when aria-support is turned on, this button becomes focusable. Tabindex="0" is added to the span inside the text box. We prefer the older functionality where the button was not a tab stop. Which is the same behavior you have when aria support is turned off. For reference, see your own aria demo:
Note that the tab key stops on the drop down arrow. (You can check the previously linked demo and see that the arrows in those boxes are not tab stops.)
If right-click the arrow and inspect, you'll find the following:
<span id="ctl00_ContentPlaceholder1_RadComboBox2_Arrow" class="p-icon p-i-arrow-60-down" role="button" aria-controls="ctl00_ContentPlaceholder1_RadComboBox2_listbox" tabindex="0"></span>
Adding aria support should not change behavior, so we'd prefer the tab stop was removed.
In our own application, we have additional problems when the button is focused and activated with either the "space" or "enter" keys, it refocuses the field, but it does not actually open the drop down. I do not see that problem in your demo. However, if the arrow button was removed as a tab stop and from the INS+F5 dialog, this would not be a problem.
Please note that all of the above is in Chrome.
Using the following code in the OnClientLoad event of the ComboBox:
var _DropDown_OnClientLoad = function (sender, args) {
var input = sender.get_inputDomElement();
//Remove tabindex from down-arrow button. We never want to focus this button.
$telerik.$(input).siblings("button").find("[role=button]").attr("tabindex", null);
//hide the down-arrow button from screen readers. The entire combo box
//should be considered a single control.
$telerik.$(input).siblings("button").attr("aria-hidden", "true");
}