How to upgrade StdPeriph drivers for STM32F103 project
If it ain't broke, don't fix it.

The StdPeriph drivers work very well on existing STM32 MCUs, and these are going stay around for a while, as long as ST renews its 10 years longevity promise every year. 

The register interface of an STM32F1 that'd be manufactured in 2029 will be exactly the same as that of one built in 2007.

You have the drivers in source code form, you should have every right to use it (but IANAL), so you don't have to worry about not being able to get it in the future.

Not being developed further by ST means that they won't break it either. On the other hand, the STM32Cube libraries had some incompatible changes in their 5 years of lifetime so far.

Maintainability

Changing an existing software to use a completely different library would almost certainly increase complexity and decrease maintainablity and stability. There'd be wrapper calls more or less compatible with the StdPeriph interface, the less compatible edge cases causing lots of headaches. There'd be workarounds for passing STM32CubeF1 data structures (so-called handles) around.

Scalability

You are already aware of the fact that STM32Cube has severe performance problems, so introducing it would be rather counterproductive when scalability is an issue.

StdPeriph drivers exist for the STM32F4 family, which would be the next logical step up from STM32F1.

There are no StdPeriph drivers for the F7 and H7 family, but some peripherals are compatible, others differ only in register layout and some additional functionality, so porting existing drivers would not be a big issue.

Perhaps surprisingly, StdPeriph should work on the STM32MP1 series, because the Cortex-M4 part of the processor is compatible with the STM32F446, for which an StdPeriph driver exists.