The IIR runs at a reduced rate compared to the sample rate.. For example, if the sample rate is 100 MHz, the hardware clock is 25 MHz. That's why the architecture is so weird like you said.
For the record, it is really hard to meet timing closure in an FPGA when the samplingfrequency is higher than 100 MHz because of the combinational delays between the flip-flops (delay elements). There are strategies to work around this problem :
Split your order-2 or order-1 IIR filters in parallel filters and run them at a reduced rate and combine the outputs to get back to your original sample rate.
Or, use a technique like scattered look-ahead to increase the order of your IIR filters, from 2 to 4. Or from 1 to 2. By using clever pole-zero cancellation, you can meet the timing margin more easily. I used this technique in the past.
In the image below, I explain what causes the combinational delay for a simple IIR order-1 filter. Bottom line, the combinational delay must be less than the clock period, otherwise you will not meet timing closure. For example, if the clock is a 100 MHz and Tcomb = 25 ns, you will not be able to run this filter at 100 MHz. You will need to split it in 3 or 4 parallel filters that run at 33 MHz or 25 Mhz. Then you combine the outputs of the parallel filters back to 100 MHz.
As soon as the number of cofficients is high (assume 3 numerator coefficients and 2 denominator coefficients a1, a2), and I can assure you that meeting timing closure can be really hard. That's why these parallelized IIR filtering techniques were created.