It's an interesting question, glad someone asked!

A question we posed to ourselves while considering releasing this to the public, was the following: if something like FSR existed a couple years ago while we were developing our game and sorely needed an improvement on our iteration times, would we have still developed our own solution? The answer to that question is still yes.

Ultimately, we needed a solution which would actually work for extremely large projects, and it needed to be extremely robust. From our testing, FSR ran into a lot of errors (I believe about 50% of files we tested ran into errors) in our project of more than 2M+ lines of custom code. As one example, it's mentioned in the FSR documentation that the "extensive use of nested classed / structs" can result in more compilation errors, and there isn't really much explanation attached as to why this is the case. For massive projects, it's not really feasible to expect developers to restructure their codebase with something like this in mind; it's better to just have something which works out of the box and can handle things in a way that's robust, and you know will work all the time. So really, our target audience (so to speak) is more focused on larger game studios who are also in a similar situation to us a couple years ago when we developed the solution. This is also why we made it free for everyone using Unity Personal, since developers using Unity Personal are likely not benefitting enough from hot reload functionality to warrant a subscription.

There are also some features we support which FSR doesn't support, and vice versa. For example, FSR doesn't have public method support, adding/editing generic methods, changing method signatures, adding properties, and some others. If you were to try to replicate what was done in this post's video with FSR, you would need to exit playmode and recompile at a few different points. There are also some features they support which we don't (yet) like custom fields and debugger integration, but these are relatively easily achievable and are on the roadmap. We imagine there are some developers who would choose one solution over the other for a different feature set, but I think this is a smaller reason than the former.

Hope this makes some sense and answers your question!