What is gained is a much faster SFC implementation, and much less error-prone data handling.
When the code is auto-generated, serialization, deserialization and such is handled "correctly" (ie, in a method that is "best practice", based on the language/platform targeted by the artifacts that are output for them).
Reformatting a pattern is as simple as changing the input and recompiling. The output can be merged with an existing method on the CryptoServer, or it can be used as a new SFC. Java or C++ host applications can use the regenerated OOP classes directly, and a decent GUI programming IDE would assist in updating existing applications to use the new classes. There is less chance that code artifacts are missed (resulting in a disconnect between serialized buffers and deserialization attempts).
Time-to-market is significantly improved.
When an implementation of the target functionality already exists in C, it can rapidly be converted to a public method, and then wrapped with an external method, simply by conversion of its method signature to a cmd struct, matching
that struct to a pattern, and recompiling the module.