The problem I am running into is that when the page is up and active, the robot's performance drops to a crawl!
As you discovered, the REST interface method is not ideal for your application: whenever a request comes in, the sketch must stop what it's doing to parse and process the request. This can be inefficient. I think you are on the right track to off-load the web processing to the Linux side.
In my case, since I don't need a real time interface to/from the web page, making use of the Mailbox functionality sounds like the solution.
I disagree. My understanding is that the Mailbox class implements a type of guaranteed delivery message queue. This isn't necessarily what you want here: it's not important that every update make it out to the web page, you really only need to display the latest update.
I agree you want to periodically send data from the sketch to the Linux side. This data should be sent all the time, not just when the web page is requesting it. Send it at the end of each pass through loop(), or send it once a second, or something like that. Then, the Linux side should handle all of the web processing with no further involvement from the sketch.
I see a few ways to do it of of the top of my head. This list is ordered from the easiest to the hardest, but it's also what I believe to be the highest overhead to the lowest:
2) Process class - the sketch uses the Process class to start a Linux side process. Then, it periodically calls the write() function of that Process object to send the sensor data. The Linux process (probably Python?) then reads from standard input, parses the sent data, and updates some variables to track the latest values. You then need a CGI script or some other process that can get called from the web server to read and return that data. (A more experienced Linux programmer will have to give some shared data advice on how to do that.)
3) Raw serial - this is very similar to option 2, but bypasses the Bridge library completely. The sketch opens Serial1 and periodically sends the data. You will need to write a Linux process that is automatically started at boot time, which opens /dev/ttyATH0 and reads the serial data from there. The rest is the same as option 2.
d) and in the near future have the web user initiate a command from the page and send that back to the arduino (Probably use Rest for this)
REST is an easy way to do it, but once again the handling of the request and parsing of the data will slow down your sketch. Another option is the Mailbox class: this is an appropriate use for it: it offloads a lot of processing to Linux, and the sketch need only poll the Linux side occasionally to see if a message is available. You could also do it with Bridge.get() but Mailbox would work better in this case: if you send the same message twice, you will still get both messages, which is not necessarily true with Bridge.get(). Basically, the web page makes a request of the form http://arduino.local/mailbox/xxx, and the sketch can read the messages using mailbox.messageAvailable() and mailbox.readMessage(). See the Mailbox example.
Using REST, Bridge.get(), or Mailbox is compatible with options 1 and 2 above. If you go with option 3, then you will need some sort of CGI script on the Linux side to handle incoming requests from the web server. This will have to forward the request to the Linux process talking to the sketch, which will send it to the sketch where the sketch can parse it and act on it.
Put some thought into the design, pick one of these methods (or another) to try, and I'm sure you can get some more detailed help if needed.