Certainly you may call FreeRTOS directly, and then your code size will be smaller and it'll execute faster too.
Cube uses CMSIS_RTOS so it can (a) easily ditch FreeRTOS if ST find cause and (b) easily integrate third-party middleware, e.g. lwIP.
Once you've shipped you product and you're only adding odd features to make customers happy or to better position the product in the market, and you're not changing/generating your Cube configuration, you'd only update the Cube and/or FW package if you really really have to, e.g. for a security-fix, because (a) it's a lot of effort to find and fix the new problems it'd cause and (b) it won't increase your sales.
So the only risk to using FreeRTOS directly is ST ditching FreeRTOS before your development's ready, and then you'd have to change the parts of your app using FreeRTOS directly to use the next RTOS.
The CMSIS_RTOS wrapper is in "Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS\cmsis_os.c". Mostly it's wraps FreeRTOS directly. But CMSIS_RTOS numbers task priorities differently, and Cube wants to create at least one task and start the scheduler in main.c, and as you design and implement your app you'd want to plan your task priorities in one number space.
So in my apps I create tasks with CMSIS_RTOS and do mostly everything else with FreeRTOS direct.
> When I try to call notifier functions from FreeRTOS directly <snip> the debugger falls over
This is all documented many places on the web. https://www.freertos.org/RTOS-task-notifications.html boasts notifications are 45% faster than semaphores!
TaskHandle_t myThread;
<snip>
// creating the thread
osThreadDef(myThreadName, MyThread, MY_THREAD_PRIORITY, 0, MY_THREAD_STACK_SIZE);
myThread = osThreadCreate(osThread(myThreadName), myArgs);
<snip>
// notifying from an interrupt
vTaskNotifyGiveFromISR(myThread, &taskWoken); // &taskWoken = null if don't care
<snip>
// notifying from a task
xTaskNotifyGive(myThread);
