Are there platforms where disabling/restoring interrupts from ISR should be done differently than from non-ISR context?
I believe there are several more driving forces for having two sets of functions, than you have mentioned.


Those RTOSs are designed to be portable to many different processor
Instruction Set Architectures (ISAs), and they also try to ensure
developers can write systems which are portable. So they have to
accommodate all of the variability of processor ISAs in ways which
hide the differences between ISAs from the RTOS users.
Some of the ISAs used under an RTOS have both 'user' mode, and
'privileged' mode. 'User' mode will not have access to all of the
system, and specifically might not be able to block interrupts.
Further some of the functions might not be able to run in 'user'
mode, and may 'trap' to a privileged mode exception handler to
actually do the work. So having two 'name spaces' aligned to the two
CPU privilege states might be helpful to the RTOS and application
developers.
IMHO it is much easier to remember to use a function from one
'name space' (e.g. 'user' mode) than it is to figure out exactly
which function can be used in any specific context. Specifically, it
is much easier for all the functions to come in a 'user application'
name space, and a 'privilaged-system-component' name space. So, even
if the code is identical, it is simpler for the application
developer to use the functions in the 'application' or 'user' name
space. If that is an advantage for the application developer, then
it is more helpful for  for the RTOS provider to 'duplicate' the
code, into a function in the other 'name space' than not have the
duplicated function.


Summary: IMHO having two sets of functions, effectively constituting two different 'name spaces' ('user application' and 'systemcomponent'), makes it easier for the 'application' developer, and developers adding extra 'privileged-system-component' to use. 

It might also be easier to have two different function sets to make it easier to manage interrupts raised during the code running in two different system states. 

It may be relatively straightforward to create the two alternatives using some carefully thought out pre-processor macros, to minimise code duplication.

If you are not intending anyone else to use your OS, or your OS will treat exceptions raised  during 'user' mode and 'system' mode identically, then you can probably ignore the idea.

However, if you don't know how it might all work (for example this is the first time you have written an RTOS), or you think it might change, then you might want to think carefully about how you would re-introduce the two 'name spaces' part way through developing your OS.