Host metrics are not a capacity assessment, even if they enable some educated guesses.
There is no way they can predict if, say, due to organization growth the load on this box will increase by 10x. Nor will they analyze the workload. The load average will not tell you if jobs are single threaded, and you would get much more work done running things in parallel.
That said, let's make some guesses.
Storage, can't tell much. CPU load doesn't tell anything about the IOPS, or if the throughput saturates the storage system. Faster solid state is usually a good idea, yes.
Memory is possibly slightly underutilized. Depending on the database, this probably means that shared memory could be increased a bit to get a larger cache. Actually, the memory to CPU ratio seems relatively small for a database.
CPU is very underutilized, on average 5%. This can be a feature like it is for Stack Overflow, who remains fanatical about response time even if one box takes all the load. Or it means you are paying for way too many CPUs as your performance objectives can be achieved with half of them.
While the load is above 1, I believe the bottleneck is RAM and disk,
not CPU, and so the load should remain unchanged, if not decrease with
the increased RAM and faster SSD.
No, that is not what load average 1 means. Load average is the number of tasks ready to run, and on Linux also includes uninterruptible sleep. On this 32 CPU system, any load under 32 means all tasks who want a CPU are getting one immediately. It doesn't say anything about where the bottleneck is in the overall system.
To find what the slowest component is, do a systematic analysis such as the USE method.
You have a capacity planning decision to make, fewer CPUs and faster SSDs as proposed or not. Does the current spec meet your performance requirements? The cost structure will be different if you own the hardware and just pay power, versus if you rent it and the many CPU box is at a price premium.
Risks you take on this are mitigated by how easy it is to undo. If you can get the working size again, that's easy to migrate back.
P.S. Schedule a maintenance window for patching. Any UNIX or Linux has important updates in that 412 day uptime that are not applied.