There are a few more points to consider IMHO:

1) disks (regardless which technology) will over time malfunction and need to be replaced. There is some effort involved in such a replacement. SAN systems have usually ways to - more or less - "effortless" replacing disks built in because they usually are used to deal with a lot of disks and the chance that one disk malfunctions rises with the number of disks involved. You might want to do some risk calculation based on how often on average you expect a disk to break (there is usually a "MTBF" - "meantime between failure" number available), how long you expect the change to take and how much a downtime of the expected duration will cost.

2) SANs and local disks do differ in the way they are attached to the system. Local disks may use SCSI or the "M.2" interface. Notice that you cannot have several local (SSD-) disks attached via M.2. SAN, onthe other hand, may use a FC-connection or even several FC-connections in parallel (FC-drivers allow this for redundancy as well as load-balancing). The capacity of such FC-connections may by far exceed the speed of local disks. On the other hand you will need not only a SAN but also a FC-switch (Brocade are the most wide-spread) and the administration ("zoning") will be more complicated.

3) SANs - if set up with this in mind - may add redundancy and thus high-availability to the system. Again, it depends on the system, its purpose, etc.. to calculate properly the risk of it failing for some amount of time. Calculate how much it would set you back to have the system offline for: 1 hour / 1day / 1 week and this will give you an idea how much money spent on preventing these kinds of desasters is worthwhile.

4) SAN systems for themselves are rather expensive. To alleviate this they become cheaper and cheaper (in comparison to local disks) the more you virtualise and the more systems use it. So, a plan to buy a SAN system for a single system only might be on the expensive side but with a expectation of adding other systems using it too the costs may still be reasonable. So you may want to rethink your immediate problem in a more gobal context.

5) Notice that for a system optimised for speed you need an adequate backup solution. For this you also need a disaster scenario plan to estimate what the costs could be and hence how much the prevention may cost. Then you know how fast a recovery needs to be and therefore which technologies you need to employ to get that speed. You can use a SAN also for snapshots (perhaps quickest way of recovering a "point in time"), very fast medium to put an online backup to, only then migrating it to slower media like tapes and similar solutions. You might want to take that also into consideration.

I hope this helps.

bakunin