At those speeds the problem is that the CPUs are not fast enough. Say you need to process these 25 Mpps (and that's being generous, the maximum packet rate at 100Gbps is 162Mpps), in a single core at 3,6 GHz: you have 144 clock cycles per packet. A cache miss or a branch predictor miss will already eat quite a lot of the available time for that packet. Even if you split the workload among multiple cores you're still pretty limited in what you can do. And if you need to forward those packets, you might be close to the PCIe 3 x16 maximum efective bandwidth.

In my company we're developing traffic capture/analysis software at 100Gbps (which is orders of magnitude faster than IDS/IPS) and in order to achieve those speeds we need fast processors with a lot of cores and quite a lot of RAM, interact directly with the NIC buffers (we use DPDK now, we previously worked with modified drivers) avoiding the kernel entirely, and we have to limit the tasks per packet a lot to the point that flow state management is pretty difficult, and TCP reassembly looks impossible. I don't see a software IDS/IPS system getting anywhere close to the performance of an FPGA.