RPi GPIO speed issue in bare metal
The root culprit is a combination of hardware/peripheral limitations and clock configuration. While I have not had to work with BCM Baremetal specifically, these are common problems of baremetal projects on any complex architecture. 

As a hint on the limitations of the GPIO output drivers, you can see that when hardwired as hardware clock output the maximum output frequency is 125MHz

From Page 106 of the BCM Peripheral Datasheet you provided


  Operating Frequency:
  The maximum operating frequency of the General Purpose clocks is ~125MHz at 1.2V but
  this will be reduced if the GPIO pins are heavily loaded or have a capacitive load.  


This is in the context of configuring the GPIO peripheral to output the peripheral clock directly without software toggling. 

I would say that it is reasonable to expect even if the clocks are configured properly and the CPU running at maximum rate, you cannot expect a GPIO toggling faster than this due to hardware limitations. 

AKA just because the peripheral may latch your software command in time, doesn't mean the physical output driver transistors, which are big and beefy, with a lot of inherent load can switch as fast as your code can run. If you are doing tests it is imperative that an oscilloscope with sufficient analog bandwidth and high quality probes are used, because you are also changing your result with the measurement system. A logic analyzer may not be sufficient, a slow slew rate is not identifiable with thresholded inputs. 



How to Proceed

It seems that if your goal is to drive GPIO as fast as you need, for clock purposes, you should use this built in clock output pins of the peripheral. These are configured through registers

CM_GP0CTL CM_GP0DIV (repeat for gp clock outputs 1 and 2)

Then depending on the results of this you will identify the maximum switching frequency for your hardware system taking into account the maximum GPIO load and the VDD of your PIO circuit. 

If the clock output is slower than expected for your nominal divider settings this would indicate that you have not configured the system clock, clock routing, and PLL's appropriately.  

Once you have identified that disagreement you can tweak your bare metal bootstrap code to configure the PLLs and  see if a software controlled toggling can be made to run as fast as the hardware controlled clock output and go from there.

Additional contributing factors may lie in the Instruction and Data Caches, which require software configuration, if you are unable to align the software toggling with the hardware limit through PLL alone that would be the next place I would look.