Bitcoin has to maintain some balance to be able to retain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of fully validating the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for convenience or lower transaction fees, but this comes at the cost of decentralization. What the limits for this are is debatable to some extent, but there are clearly hard limits to avoid.
Most notably it's difficult to undo mistakes in this area of the system design, going too far with resource usage is effectively a permanent decision so you will find that choices have been made as conservative as reasonable.
We have the following limitations to contend with:
Size of the block chain. It is often advantageous to store previously validated information, even if it is not immediately required for the operation of the system. It makes wallet management easier and allows for easy re-synchronization if required. The limit of this can not be above reasonable cost or the size of volumes available to the mass-market.
Growth of the block chain size on dish currently is bounded by the block size limit. Knowing that 6 blocks happen on average per hour, and they can be a maximum of 4MiB when fully saturated with Segwit transactions, we have a bounded growth of 210 GiB per year.
Nodes can disgard these blocks once validated to avoid storing them, but the entire set must be transmitted to them in some form, typically over the internet but could be done via Bluray, Fedex, or carrier pigeon if this was cheaper or required. This is a limit for the size of the growth, as it must not exceed the ability of users to obtain the data needed to validate.
Size of the UTXO. The Unspent Transaction Outputs database is the storage of units of Bitcoin that have not been spent. This is consensus critical and must be stored by all nodes in the network who are fully validating. This database has looser restrictions on its growth, and is effectively bounded by the block size as well, as it implicitly limits the number of entries which can be added to the database. Unfortunately there is not much to be done to reduce the impact of this 4 GiB storage on disk without much larger economic changes to Bitcoin to allow for entries to be "archived".
Validation complexity. The transactions within the chain have a cost associated with their validation. ECDSA is used in Bitcoin due to it being extremely space efficient and suitable for the task, but it is not particularly fast even with completely optimized implementations. Synchronizing the Bitcoin chain involves billions of individual SHA256 and ECDSA operations which puts a hard limit on the number which can be performed by a consumer processor in a reasonable amount of time. The growth of the chain should not exceed the ability for reasonable, consumer hardware to complete validation.
