On-device bandwidth is PCIe 3 x4 (~3.5GB/s full duplex). The FPGA is separate from the SSD controller, which is an off the shelf Samsung controller. A portion of the FPGA's resources are used as a PCIe switch: the FPGA is connected to the host PCIe link and presents one PCIe endpoint for the FPGA and one for the SSD that is connected through the FPGA.
Other companies in the computational storage area are putting compute resources onto their SSD controller ASICs so that the compute doesn't have a PCIe bottleneck between it and the NAND. But you won't see that kind of design coming out of a Samsung/Xilinx collaboration.
If these drives are just fpgas sitting on the existing interface, so still hitting the PCIe limits, then this is un-impressive. If we start seeing multiples of device bandwidth available to the FPGA, then we can see huge cost savings.
I agree that on its own, it doesn't seem too interesting for the FPGA to be accessing the flash through the same PCIe x4 interface that the host system could use. But servers with 24+ NVMe SSDs don't always have the bandwidth to saturate all the SSDs simultaneously; they're often connected through a PCIe fanout switch that has just an x16 uplink (or an x16 per CPU socket). Having an accelerator to offload eg. search means the drives in aggregate don't have to send as much data up to the CPUs (or NICs). Even if these drives have what appears to be a sub-optimal design, they can still help alleviate bottlenecks elsewhere.
Other companies in the computational storage area are putting compute resources onto their SSD controller ASICs so that the compute doesn't have a PCIe bottleneck between it and the NAND. But you won't see that kind of design coming out of a Samsung/Xilinx collaboration.