I had heard that it wasn't suppression as much as just not making it a thing at all, and that AMD used the opportunity to extend x86 to 64-bit, and Intel was essentially forced to follow suit to avoid losing more of the market. It also explains why the shorthand "amd64" is used; Intel didn't actually design x86_64 itself.
I've still got a couple small business models along these lines that are over 20 years old now. Still running possibly because I always turn them fully off when not using them. No hibernation, sleep or other monkey business.
One Dell has an early 64-bit mainboard but only a 32-bit CPU in that socket, just fine for Windows XP and will also run W10 32-bit (slowly), mainly dual booting to Debian i386 now since it retired from office work. Puts out so much heat I would imagine there is a lot of bypassed silicon on the chip drawing power but not helping process. IIRC a 64-bit CPU for that socket was known to exist but was more or less "unobtanium".
Then a trusty HP tower with the Pentium D, which was supposedly a "double" with two x86 arch patterns on the same chip. This one runs everything x86 or AMD64, up until W11 24H2 where the roadblocks are unsurmountable.
To this day, I don't know if Intel thought Itanium was the legitimately better approach. There were certainly theoretical arguments for VLIW over carrying CISC forward--even if it had never been commercially successful in the past. But I at least suspect that getting away from x86 licensing entanglements was also a factor. I suspect it was a bit of both and different people at the company probably had different perspectives.
Internal inertia is a powerful thing. This was discussed at length on comp.arch in the late 1990's early 2000's by insiders like Andy Glew. When OoO started to dominate intel should have realized the risk, but they continued to cancel internal projects to extend x86 to 64-bits. Of which apparently there were multiple. Even then, the day that AMD announced 64-bit extensions and a product timeline it should have resulted in intel doing an internal about face and acknowledging what everyone knew (in the late 1990's) and quietly scuttling ia64 while pulling a backup x86 out of their pocket. But since they had killed them all, they were forced to scramble to follow AMD.
Intel has plenty of engineering talent, if the bean counters, politicians and board would just get out of the way they would come back. But instead you see patently stupid/poor execution like then still ongoing avx512 saga. Lakefield, is a prime example of WTFism showing up publicly. The lack of internal leadership is written as loud as possible on a product where no one had the political power to force the smaller core to emulate avx512 during the development cycle, or NAK a product where the two cores couldn't even execute the same instructions. Its an engineering POC probably being shopped to apple or someone else considering an arm big.little without understanding how to actually implement it in a meaningful way. Compared with the AMD approach which seems to even best the arm big.little by simply using the same cores process optimized differently to the same effect without having to deal with the problems of optimizing software for two different microarch.
Sophie Wilson (ARM instruction set designer) was very enthusiastic over her "Firepath" architecture that had VLIW aspects.
It was targeted at DSL modems, and I think the platform has faded and is now somewhat obscure.
https://royalsociety.org/people/sophie-wilson-12544/
https://old.hotchips.org/wp-content/uploads/hc_archives/hc14...
Intel and AMD have a cross licensing agreement where they pay each other the right to use various IP. One of the things Intel pays AMD for is x86_64.
There was apparently earlier Pentium 4s that supported some version of a 64bit isa, support for which was fused off before sending to customers in order to convince people to move to Itanium.
https://www.tomshardware.com/pc-components/cpus/former-intel...