I'm not trying to sound harsh, I just don't understand when I'd ever need to do something like this.
tableName.rows[rowNum].cells[cellNum]
Instead of loading all of that into a variable (a second time, it's already an object on your page), trying to keep it in sync, binding events in both directions to keep it in sync, the load of doing twice the work, the lag of redrawing the entire table every time you want to do something, etc..
I don't see why this is cleaner than working on the DOM. I've done this a number of times and only found headaches when trying to build something larger than a silly toy or a list of 30 items on a table. IIRC DataTables did something like this internally last time I looked at it, and that thing konks out and either slows down your page or crashes the browser depending on how many cells you load into it.
Also, for things like plain-text searching, it's faster to do it on a collection of objects detached from the DOM in JavaScript than to scan the DOM, and especially if you're doing non-text comparisons (like comparing a number with the parseFloat representation of the values in one of the table columns for all rows).
And finally, if you are going to read and then redraw in the DOM, it's best to do it as grouped atomic operations due to the inefficiency making the browser reflow (https://developers.google.com/speed/articles/reflow).
For what it's worth, this is how Dynatable works internally, though I haven't had any issues with it being slow, though it's possible I just haven't used it with large enough data sets yet (I've only used it on tables of probably 1000 rows or less so far).
Why not just send back to the server instead? First, sending the JSON back turned out to be faster than rerunning the query. Second, datatables has a full text search option which made things simpler for our case.
(Datatables has an export plugin, but it uses flash and only generates thinly-veiled CSV.)
So there's a use case for something like this.