The big deal with cut through in storage applications is that you should be using jumbo frames in pretty much any storage application. Even if your hardware is capable of receiving at line rate it will significantly reduce the CPU load of processing that flow. That said, it is virtually assured that no matter how nice your hardware is, it is going to struggle to cope with single-queue flows approaching 40Gbps in the traditional "kernel network driver, user mode application" style due to the enormous context switching overhead involved and anything you can do to reduce that (using larger frames) will improve both realized performance and reduce the CPU load.
If you are using jumbo frames with a store and forward switch, that means waiting for a 9000+ byte frame, or about 7.36 microseconds best case at 10Gbps.
Cut-through switches of this class begin to forward at the worst in under a microsecond, usually on the order of around 200 nanoseconds, and in some (very expensive) cases even faster than that.
In a local network at these speeds forwarding and serialization delays are rather significant, anything above 2.5 microseconds for a 40Gbps link would be considered a "long, fat network" in bandwidth delay product terms. So, even the storage traffic will see some gains in efficiency due to the reduced significance of buffering, but in "converged" networks with some workloads that are particularly latency sensitive it can be even more significant.
Cut through will only be utilized between ports of the same speed, as aero notes, but as you suspect you can use 4x10 breakout mode and LACP to get aggregate multistream bandwidth of 40Gbps with cut-through. You will need to use a storage protocol that makes use of multiple flows or have a diverse multi-user access pattern to properly utilize 4x10G breakout in this way.
I would disagree with aero's suggestion to consider Infiniband very strongly. I used Infiniband for almost 10 years (DDR, QDR then FDR) and over that period it was actually supported by a recent vanilla kernel for between 12-16 months. The rest of the time I was either forced to remain downlevel and sacrifice other features or forced to fall back to IPoIB because Mellanox can't write a functional driver or bother to support any of the 3 or so applications that actually use RDMA to save their lives. I even briefly fell back to gigabit ethernet, because of a kernel bug which degraded IPoIB performance to <100KB/sec which ran concurrent with the entire-3.x-series-kernel NFS/RDMA bugs.
I use 2x40GbE to realize FDR Infiniband performance (on throughput, admittedly nothing really tries to compete seriously with RDMA over Infiniband on latency) without overly complicating my stack these days, and I'm going to be slowly replacing my remaining Mellanox Ethernet NICs with literally anything else, because the DPDK and RoCE drivers have the same problems.
