You could check if you can use a GtkTreeListModel as the model, and GtkTreeExpander as the widget in the factory you pass to the GtkDropDown, and see what happens.
In general, piling complexity inside a GtkDropDown is not a great plan, just like piling complexity inside GtkComboBox; sub-lists inside GtkComboBox were never really well supported, and it was more of an accident.
Then, may I ask, from the gnome HIG point of view, how it should be done ?
Let’s say, for example, we have the typical case of Country/City.
With sublist, the user can select the country and then a city from the selected country.
But now, since we cannot do this anymore …?
I’d recommend using a search approach, with the results inside a drop down, similarly to how search for a location is implemented in applications such as Clocks and Weather.
If you know the amount of levels, like Country / City, then you can separate the selection into separate drop downs, and keep each drop down to a single level.
In the example above, it seems you’re browsing through interfaces; in that case you really want to have a list with all the the interfaces always visible inside something like a side bar.
The main point is that visually scanning through a long list of things isn’t helpful, especially if you have to find something through multiple levels in a scrollable thing that may or may not disappear as a pop up.