[Ginto8]

The biggest problem I see with calling an update function in a periodic function or having a Command update it is that it breaks the idea of what a Subsystem is supposed to be. Subsystems should be standalone classes with internal state corresponding to some aspect of the robot (eg. sensors, motors) with simple, non-blocking methods that modify that state. Having a periodic update function muddies that picture of a Subsystem.

So if updating from periodic or a Command violates the Subsystem's Subsystem-ness, what can be done instead? The answer was mentioned: make a background thread contained within the class. If you look at WPILibJ's PIDSubsystem, its interface is extremely simple: you have a couple ways to set the setpoint, and a way to read the current "position" (sensor value). Internally, however, there is a TimerTask acting as a PID feedback loop, working periodically. This thread is entirely encapsulated within the Subsystem, and allows the interface to be as simple as it is.

So define a Subsystem to work how you want to think about it: if you want to think about an arm as having a height above the ground, then make that the interface, leaving the rest of the details encapsulated within. If you want to think of a shooter wheel's speed in rpms instead of in [-1,1], you can do that, and implement some sort of feedback controller (like PID or bang-bang) internally. Subsystems are supposed to provide a useful interface to the robot's hardware so that commands can be simpler; sometimes, this means sacrificing a simple implementation (eg. motor power going to an arm) to make a more powerful interface (eg. setting the arm's height, allowing presets that can simplify both teleop and autonomous in a game like Logomotion).

As a rule of thumb for this design, if your Subsystem interface does stuff, you should rethink your setup. A Subsystem can do stuff internally, but its interface should be solely concerned with setting things. Doing things is the Commands' job.