My impression was that in 601-1 they kind of confused things by referring to "architecture specification". In IEC 62304 they use "architecture design" which refers to the breakdown of the system into units. This breakdown is optional and depends on a lot of factors such as how well established the software is, criticality, importance of segregation (e.g. protection software from control software).
For a larger system including software and hardware, the principle is the same. As in IEC 62304, the degree and structure of breakdown is optional. You could call a block "motor system" even though internally it could include voltage regulators, motor drives, feedback sensors and the motor itself. If it was an off the shelf component from an approved supplier, or a sub-system that's been used for 10 years without trouble, or not that critical, that simplistic approach might be OK. But if it was custom built sub-system and/or has critical safety features, you might break it down further to enable better testing before placing on the market.
Plus, for high risk devices segregation is important to show in architecture. For example, if the data from the motor encoder is used for a risk control measure (motor going too fast, too slow or stalled, which could kill or seriously harm a patient) it makes sense to ensure that it is isolated or independent from the control system. An architecture is the place to show this. In that sense, the architecture is a specification, in that the isolation from a control system is something that should also be verified, ideally by engineers that are not involved with the design. This aspect - verification of independence in risk control measures - is often overlooked as an activity in the verification process.
