I think exploits of these classes will disappear completely in CPUs in the next architectural cycle
That's probably a little too optimistic. This class of problems -- microarchitectural side channel attacks -- have been known since 2005  but used as attacks on cryptography systems. The introduction of crypto instructions into general-purpose CPUs attracted cryptography researchers interested if the same techniques could be applied to general purpose processors; culminating in CacheBleed , etc. Given that success the researchers have more recently applied the techniques to finding and exploiting microarchitectural side channels against other processor functions -- mostly using cache timing side channels . In this latest case the side-channel is instruction speculation. But general-purpose CPUs have many other side-channels that have yet to come under close scrutiny.
The Intel "Meltdown" flaw can be easily fixed with a revision to an existing design, as a bump within a generation. Assuming Intel want to sell CPUs in the next few years, we can assume they have spent the past six months working on such a bump.
The speculative-execution "Spectre" flaw in all Intel, AMD, POWER, zSystem, SPARC, MIPS, ARM models with speculative execution can be fixed with an architectural modification. As you say, by the next architectural cycle. Of course there is considerable business risk attached to that simple statement: you wouldn't want to be the firm trailing other CPU designs which have already corrected the flaw. As a result this flaw is likely to lead to a shortening of the expected CPU design cycle (which is usually based upon process changes, rather than microarchitectural security enhancements).
Closing that "Spectre" speculative-execution side-channel doesn't solve the problem. There are so many side channels in a modern CPU that researchers will simply find another. Which will in turn take another architectural change to avoid. You can see what may happen here with a "whack-a-mole" approach: there may rarely be a point where a CPU doesn't have a known and exploitable vulnerability. This isn't to say that the Spectre mole should not be whacked, but that this whacking won't be sufficient to ensure security.
To avoid this outcome processor designs will adopt the same rigorous approach to side channels as done by their cryptography semiconductor design counterparts. That learning, process re-engineering and re-design is unlikely to take just one architectural cycle to complete. It also contains cultural challenges for semiconductor companies as this sort of security is very much about control of the design process itself, and to date semiconductor companies do not divulge the finer details of their designs nor the finer details of their design processes.
You could expect cloud providers to demand such fine detail before making a major investment in a company's CPU for their compute cloud. Imagine being a compute cloud provider today -- somewhere between 10% and 30% of the CPU cycles they have paid for are gone, and they have clients upset by being charging the same price for less processing throughput. Cloud providers will probably need to reduce pricing for some clients whilst at the same time putting aside cash for a wholesale replacement of all their compute cloud CPUs (and thus mainboards).
It's good news that the Raspberry Pi 3 with its non-speculative Cortex A53 is clear of the current mess. There is no guarantee about what other possible side-channels may or may not be present for future similar events which I expect in the coming years. No large-sales semiconductor design has yet done the groundwork to be able to give such assurance.
 DA Osvik, A Shamir, R Tromer, "Cache attacks and countermeasures: the case of AES". 2005-11.
 Y Yarom, D Genkin, N Heninger. "CacheBleed: a timing attack on OpenSSL constant time RSA". 2016-10.
 Y Yarom, K Falkner. "FLUSH+RELOAD: a high resolution, low noise, L3 cache side-channel attack". 2014-10.