Our emphasis with Strongback was on testability: make it easy for teams to write good, testable code and simple tests that can be automated and run frequently (on laptops) to catch regressions. The API uses lots of interfaces (many of them functional) that isolate your code from hardware-related WPILib classes, making it very easy to unit test your code using Strongback's mock implementations. The API doesn't get in the way, either: it let's you write robot code in much the same way as with WPILib, except that you use Strongback's hardware interfaces instead of many of the WPILib classes. And to keep things lightweight and minimal, we use a lot of lambdas and functional interfaces.
Additionally, since you can't unit test everything and its very difficult to realistically simulate real-world physics and sensor input values (especially in response to outputs), you still will need to test your code on the robot hardware. When you do this, you want as much insight as possible into what's going on in your code. This is where Strongback's
data and event logging features come in: they provide a data acquisition system to record multiple channels of data every cycle of the code (e.g., 20ms by default) as well as spurious events like command state transitions. There is little overhead to this (Strongback uses memory mapped files to minimize latency), and these logs can then be converted into CSV files and imported into your favorite data analysis tool (we like Tableau) to understand and visualize the complete time history of activity.
Finally, Strongback is designed to be small and run all asynchronous operations on one thread and, along with the main thread, runs very well on the dual core RoboRIO. The asynchronous code was carefully designed to minimize thread context switches, resulting in quite reliable and consistent periods of execution. The makes control systems easier and more precise, since the actual delta-t is closer to the modeled delta-t of your control systems. (If your not careful, you can still overdo it by running more things asynchronously than can run in the configured period. In this case, Strongback logs warnings every time it falls behind; the fix is to run fewer things or to increase the delta-t.)