Hardware security modules
Running code in a physically-protected chip such as a HSM or a smartcard is not about protecting from software bugs. If there's a software bug in a HSM, it can be exploited just as any webserver, laptop, smartphone, whatever. The difference between a HSM and a PC is that with physical access to a PC, you can just boot from a USB stick or swap out the disk. With physical access to the outside of an HSM, you still have to break in, and HSMs are designed to self-destruct when you make a serious attempt at opening them.
Running a browser on a Raspberry Pi
A PC is a “chip-based system” as much as a Raspberry Pi. There's no fundamental difference between them: a Raspberry Pi isn't somehow “more secure” than a PC.
More people use PCs, so PCs are a more valuable target to exploit, so more people try to exploit PCs. PCs also have a heavy burden of historical compatibility and a large variety of software, which puts them somewhat more at risk. But if people routinely ran browsers on Pis instead of Pentiums, there'd be more exploits out there for Pis.
Moving the browser to a different machine isolates it. But what do you gain? A lot of exploits are delivered through the browser. Often the browser itself is the target. It has access to the network, so it's a valuable target to spread the infection to other machines. It's how the user interacts with a lot of things, so it's a prime target for thieves and scammers. No matter where you put your browser, if it's infected, you've lost.
Randomizing code
Randomizing code in some way is a defense technique, but it only makes exploits harder, it doesn't make them impossible.
For example, some modern operating systems practice address space layout randomization: each time a program starts, it's loaded at a different random address. This means there are things you can't do in an exploit, such as refer directly to the address of a piece of code in the original program. It doesn't make exploits impossible: there has to be a way the program can find its own pieces (for example, a short relative jump will keep working just fine), and if some piece is hard to find the exploit can search for it (it's a common issue even without ASLR because often the exploit code itself will be loaded at an unpredictable address).
Randomizing code in the compiler wouldn't buy you much, and it's expensive. All these forms of randomization make debugging harder. If you randomize before distributing the program, you have to manage the distribution and maintenance (updates) of all these different versions. And security-wise the benefit it minimal because in the end the program still has to do the same thing.
How hardware helps with security
For run-of-the-mill systems (not HSMs and the like), the role of the hardware is to enforce isolation between components. It's a hardware component, the MMU, that makes it impossible for a program to directly access another program's memory. The CPU design also makes it impossible for ordinary programs to directly access hardware peripherals, they have to go through operating systems interfaces for that. The hardware has to be used correctly: it's up to the operating system to set up the MMU tables correctly and so on.
You can't put too much intelligence into the hardware. The more you do, the more there's a risk that there'll be a bug in your design. Hardware bugs are pretty hard to fix. So the hardware provides some basic capabilities, and the complexity is handled in software as much as possible.
lynx
orw3m
for text-mode browsing. No need for challenge/response. However, these programs are not simple, nor are they perfect.