In addition to the above explanations re: sprites actually only having 8 bits of position resolution, the first column blanking option etc, the NES - and others following its same general design - actually had another, simpler, more physical tactic to address the problem: Overscan.
The pixel generator clock, derived from the NTSC colourburst crystal by some particular divider, was conveniently just slow enough that, on a "normally adjusted" CRT television (calibrated with the standard test card and other tools), the console couldn't quite show a full 256 pixels within the visible borders of the tube / bezel. ISTR your likely visible width being rated as somewhere around 240 to 252 pixels depending how well in-spec your TV is, and it being more likely that things would disappear off the left than the right due to the NES timing. Which is why on-screen text rarely goes all the way to the edges, despite how low resolution it already is.
This tactic is also used at the top and bottom, even though the 8-bit range isn't really a problem there. There's quite a bit of garbage that can be seen around the vertical borders, on emulators and I think PAL machines also (as the screen exposes more scanlines, usually a minimum of 256). The machine is generally set to produce 224 lines, sometimes 240, but yer typical TV can only display somewhere around 212 to 220 at best. Without having to do any particular work, therefore, most if not all of the junk is just pushed away off the top or bottom physical limits of the screen where no-one will ever see it ... at least, in the originally intended field of use. It doesn't therefore matter if weird things happen at the edges of the image, because, technically, you shouldn't be able to see it, or if you can it's right on the edge of the screen where the whoopsies will only be visible right near the centreline and will clip off for certain at the corners.
Just like how regular broadcast television tends to work, in fact. If you capture an old tape using a USB converter card, or even just play it on a modern flatscreen TV with way less inherent overscan (which also makes NES games look like crap, for that and various other reasons), you can see all kinds of little telling details at the margins that would have been totally invisible during the original broadcast.
As for what that particular pixel clock is, I forget exactly. It's five-point-something megahertz. 5.3? 5.7? It's a little odd in that it's derived from the slightly unusual NES master crystal that's not 4x the base colourburst, but 6x (so 21ish MHz vs the more familiar 14ish), owing to how the machine builds its colour output using a 6-bit quasi-binary pattern, so there's a different set of factors vs most other contemporary machines (other than those which use a similar video setup of course; the TI-99/4A, Colecovision, original MSX range, SMS, and Megadrive in 256px mode, are all at least close if not identical). I do know it's a little slower than 4/5ths of the Amiga's 7.1MHz (itself 2x colourburst, so it likely ain't 4/15ths of 21.whatever, which would be a weird and hard-to-engineer divisor anyway), because on the same range of TVs which exhibit the described behaviour, the Amiga (and Atari 8-bits - and C64? - before it), by a similar confluence of luck and design, manages to cram in 320 (or 640 (or 160)) pixels just inside of the overscan border, losing a few right in the corners of curvier tubes. So... less than 5.73MHz.
Probably 5.37ish? That's a nice round 1/4 of colourburst x 6, and conveniently is 3/4 of Amiga frequency - meaning mathematically it gives us 240 pixels "just" inside the overscan, with a single 8-pixel block on each side cut off by the bezel to a certain extent, or - if it's aligned more completely at the right - only a little bit missing on the right hand side, a mostly or completely missing first column on the left, and a second column which is either wholly visible or slightly cropped after it...
(NB I'm working off the on-screen appearance PAL machines here, which run just a little lower frequency than their NTSC counterparts; a US Amiga likely doesn't quite overscan even in the corners, and a US NES likely just neatly shears off most or all of the first column whilst leaving the second and all the other 30 intact... the figures are correct, however; colourburst frequency is exactly 315MHz divided by 88...)
PS, the "working out screen position from memory address without use of division/multiply" thing is... convenient for those systems which happen to have a 256- (or 128-, 512-) pixel screen width, or have the option of setting it (e.g. Atari 8-bits include the lower two amongst their many choices), but it's not universal. There are plenty of 8-bit systems (and, heck 16-bit ones which had MUL/DIV instructions but didn't exactly execute them particularly fast) where the screen wasn't a binary-aligned width - VIC20, C64, VCS, every other Atari mode, Apple ][, Amstrad (CPC and PCW), Gameboy, Gamegear... etc. Presumably there must still be ways - perhaps using modulo functions? - of carrying out the same task without spending inordinate processor time or wasting memory on huge lookup tables?