For a 0.25Hz sample rate, I think either bus should be fine. CAN has more "built in" features of message prioritization and arbitration and so on than RS-485. So you'd have a somewhat more complex but somewhat higher level protocol with CAN. The electrical signal and power supply requirements for wiring would be virtually identical for either case. You say "synchronized" sampling is required, but do not define what precision and accuracy and latency of "synchronization" is required.
If you had to have the sampling "simultaneous" within nanoseconds then you'd have some significant additional concerns relating to communications latency, wiring delays, etc. But I suspect that since you didn't define the requirement and are considering "relatively" low performance buses without mentioning any kind of triggering / clocking strobe for the sampling trigger, you may be happy enough with synchronization down to the level of several microseconds or longer. If that is the case either bus is probably potentially workable for you depending on the architecture of your system.
Do the nodes sample autonomously at the predetermined rate and sampling times? If so, that makes it easier so long as the sampling clocks on the nodes are maintained in sufficient synchronism. If the nodes each wait for a "sample now" command on the communications bus then you may want to consider what happens if the message reception is occasionally delayed or lost by one or more nodes. In such a case the synchronization of the sampling may be lost or the sampling point delayed.
How about the transmission order of the sampled data to the controller? If the nodes are sharing a common serial bus, one must send its result before the others, so there will be a chance for bus arbitration conflicts. Unless there are parallel independent buses going to each node, some nodes' data transmissions will be delayed by by virtue of being transmitted later than other nodes. How will the bus arbitration work? Will each node be polled in turn or speak in turn? How about message retransmission if acknowledgement is not received due to bus contention or transmission errors or other circumstances?
If the nodes have local clocks used to timestamp the sampling data and possibly determine the sampling times, how will the clock synchronization be maintained? So, you see, you end up with the same kinds of potential problems and potential solutions / architectures whatever bus you use. CAN provides some higher level protocol features to assist with structuring some aspects of bus contention, arbitration, prioritization, retransmission, error detection, etc. You can implement similar things in RS-485 with your own protocol. In the end the most important aspects of the communication network are the architectural decisions and requirements relating to things like fault tolerance, timing, synchronization, error detection, error handling, network design & wiring, etc.
One possibility you didn't mention is Ethernet which has been augmented in some embedded applications with PTP that helps to synchronize and timestamp events between distributed nodes. Typically the ICs and components are somewhat more expensive to implement Ethernet vs. CAN or RS-485, though that depends on your implementation choices, need for things like high levels of electrical isolation between the wiring and the nodes (possible with added circuitry in CAN, RS-485, or Ethernet, but only really expected as a baseline implementation approach in Ethernet). Ethernet gives you a possible standardized means to provide power to the nodes, though power is often run along with CAN or RS-485 too.