PR created; many thanks to you all 
Channel type does not automatically get you a thing mapping. It is M:N relation. Each channel type can be used by multiple thing types within binding, hence each thing type defines list of channels it can handle assigning them unique identifier and expected type. Way you define channel types has nothing to do with how it is being consumed with thing type as wiring is done above XML definitions by framework.
Few months ago I found that you should not be doing updates to things defined in a text configuration as these thing instances are immutable. It might be working for now, but that’s a part of framework which is not well defined.
You have to understand what means extensible property. To make it short, when set, it gives the ability to the user to add channels by itself.
If you want the binding (and not the user) to decide itself what dynamic channels to add, do not use it.
Here is an example. As you can see, you define what channel types can be added by the user. Generally, this channel type has a configuration parameter.
May I suggest that we move this discussion to the respective discussion in the Pull Request, so we can keep everything on one thread?
How then a specific channel type defined within a binding can become a dynamic one (or rather optional) for a specific thing type? As I pointed out above, channel instances are declared per thing type. Change at runtime is possible, sometimes constrained, but it is actually tricking out a framework that there are more channels than expected in a thing type definition.
Look at how I did with the SMHI weather binding as an example. The thing-types.xml only defines the channel-groups, but no channels, and the channel types are defined separately in channel-types.xml. Then, depending on how many hours and/or days the user want a forecast for, the thing handler creates channels in the respective channel groups and adds them to the thing. No extensible property needed.
If we talk about XML declarations then channel groups are not relevant to the problem of OP and I believe they are not a solution. Channel groups and appropriate group types are static holders for channels see official documentation. Till some degree, these are embedded sets of channels which you can share between various thing types.
If we take the SMHI - I think it is not a valid example as it does not have 0…1 channels enabled by thing definition itself. See my point about groups above. Fact that thing handler creates channels rather than using an extensible property in this particular case could be seen an anti pattern given what you mentioned: “depending on how many hours and/or days the user wants a forecast”. To me it sounds like a perfect match for an extensible channel. 
To move problem statement forward - I suppose OP problem is probably related to thing creation cause this part rely extensively on a thing type and its definition. If you make a given channel part of thing definition then it will always appear after creation, if you do not declare it explicitly then UI will never spot it.
Code responsible for that logic is probably here: openhab-core/bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/internal/ThingFactoryHelper.java at e20348e8d66845db841f17e6e048d789d004fdf2 · openhab/openhab-core · GitHub (below you can see there is the same logic for channel group types).
Xtext thing provider does it in a bit different way, probably copying part of this logic, which is caused by a fact that overall framework behavior was not defined earlier.
Groups or not is beside the the point, what I wanted to prove was that it is possible to define a channel type in xml files, and then create a concrete channel using that type programmatically in the binding, without using the extensible property, and it displays in the UI just fine.
Perhaps there are better ways to achieve the same result, byt having the user add every channel manually would not be user-friendly, since there are 19 channels for each hour and 24 channels for each day in the forecast. Much better imo to just have them select that hours and days that are relevant to them.