There are graph reduction CPUs like SKIM, GRIP, and perhaps most widely known, the Reduceron. (The Reduceron's instruction set is basically a subset of Haskell, i.e. a lazy functional language. It also has garbage collection in hardware.)
The FLEET and EDGE architectures focus heavily on communication. In the beginning of computing, computation was expensive, but communication (on the CPU) was practically free. Nowadays, it's the opposite: CPUs can compute insanely fast, it's moving the signals around the CPU that's the problem. But we can't influence communication: we can only tell the CPU to compute, communication on the CPU will happen as a side-effect of that, outside of our control. The FLEET architecture turns this upside down: you only tell the data where to go, computation happens as a side-effect of that.
The Azul Vega-3 CPU has a fairly traditional 3-address RISC instruction set, but its implementation is heavily optimized for object-oriented languages with dynamic polymorphism. So, it's not an object-oriented CPU, but it is a CPU optimized for object-orientation. E.g. OO code has much less locality of time and locality of space than ADT code. But most modern CPUs depend on temporal and spatial locality for a lot of their optimizations. These optimizations are mostly useless for OO languages, though. For example, memory prefetching to prevent cache misses. The Vega, instead of trying to prevent cache misses, reduces the cost of a cache miss by having an insane amount of memory bandwidth and a very sophisticated memory controller. (After all, the cost of cache misses is
#misses * cost(miss), and bringing down either will reduce the total cost.) On a Vega system, you can have tens of thousands of cache misses in flight, and still make progress with your computation.