At the time of writing, the only official guidelines for hardware are the standalone on-premise installation in the installation guide and the the ARM templates topologies: https://kb.sitecore.net/articles/043375
The ARM template topologies are based on a simple marketing site without heavy integration or customization. If you are heavily integrating with xConnect and external systems, your needs for hardware and servers will be different. I have posted some basic guidance on XP Services scaling in a Sitecore StackExchange answer, though this is not about hardware specs, more decision points for scaling:
How best can you scale xConnect to handle high traffic?
As you noted, the Sitecore scaling guide currently lacks the hardware specs for the scaled environments. These details just are not available right now. The ARM templates topologies will give you the best guidance we currently have in terms of looking at relative performance, but when scaling architectures so much is dependent on the solution that has been implemented and the way each role is being used in that deployment.
Comparing to Sitecore 8
If you compare the ARM Template topologies between Sitecore 8 and Sitecore 9, you will note that the requirements have not really changed for the core instances. Other than the new XP Services introduced (and their related components) there were virtually no changes. There was a slight alteration for CM and session state in a standalone environment, and a minor change for session state for an XP Extra Large. Otherwise, everything was identical.
What does this mean?
You could likely base a lot of the hardware requirements on 8.2 guidelines for the core instances, which can be seen in documents such as this:
The New XP Services
The tricky part comes down to how the customer wants to deploy the new XP Services. If they deploy it to the same servers as one of the Sitecore instances, that hardware will need to be beefed up to handle the extra workload. If they deploy it separately, then the hardware will depend on how they deploy the services (single app, scaled out on one server, scaled out across multiple servers, load-balanced, etc.)
The other new piece in Sitecore 9 is the SQL Server storage of xDB. This should definitely be its own server in production, and not the same server as the rest of the SQL databases. You will notice from the ARM Templates topologies that the new shard databases are smaller than a standard Sitecore database at the low end of visits, but as the visit count rises towards the higher end the shard database hardware requirements grow faster than the core content databases. This is because the content databases generally don't have more storage based on visits, whereas collection is all about tracking visitor data.
Wrapping it up
There are so many variables when planning infrastructure, it really is situational and you need to adjust your infrastructure planning to the customer's needs, their solution implementation, and their planned usage/visits. The best advice I can give is to make sure to implement infrastructure that you can easily adjust to meet your needs as they change and only pay for what you need now. This avoids the 'over-buying' that sometimes happens in on-premise provisioning.