It would either change nothing or would harness massive parallel setting like in Reduceron and its successor PilGRIM1 with a huge stack.
Statement that it would change nothing seems bold at first, but since CPU is sequential, there is a translation process (compilation) that uses available hardware to its extend for efficiency. Shall there be another architecture, some operations would be faster, some would need hacking tricks to speed it up.
Architecture that would make a difference would require map operation and lists to run faster (not the whole story, but it suffices to show the effect). There is no possibility to create dynamic changing hardware to natively run lists, so these gets stored in contigous memory. We stick to array representation of some form. For map, to run in non-sequential setting - we get back to Reduceron. So effectively one central processing for consecutive instructions, and support for parallel processing.
What might be different is possibility to load multiple functions and run them without frames juggling - but adding multiple units for functions would create a mess with accessing memory.
Adding to kne's answer, the GC would be benefitial to run as coprocessor, it would be very neat feature.
1: PilGRIM is properly described in Boeijink A., Hölzenspies P.K.F., Kuper J. (2011) Introducing the PilGRIM: A Processor for Executing Lazy Functional Languages. In: Hage J., Morazán M.T. (eds) Implementation and Application of Functional Languages. IFL 2010. Lecture Notes in Computer Science, vol 6647. Springer, Berlin, Heidelberg.