Maybe it's a little bit of a red herring to talk about point-vs-box as an alternative to box-vs-box in a thread about rotating stuff? It's really its own optimization, applicable without rotation.
With box vs box, you have to do some math to generate both boxes, then subtract and compare 4 pairs of sides against each other.
If you're going to compare a player box against many bullets of the same size, instead of generating boxes for the bullets, you increase the size of the player box once, and compare against points. Still subtracting 4 sides for the test, but now you've skipped/batched the work for generating the bullet boxes by doing them one time. This is only really useful if you have multiple items with the same bounding box size; for a single collision it's roughly the same work.
There's a further optimization if you have some kind of fast way of computing an absolute value, i.e. subtract centre point from centre point, and compare the absolute value of the difference with the sum of the widths of your two bounding boxes (precalculated once). Now you're just subtracting points on 2 axes and the absolute value operation fills in for the other two. This is great with floating point, but absolute value might be a wash for 6502 family.
tepples suggestion of sphere collision is sort of an extension of point vs point to multiple dimensions, i.e. by squaring and summing the result on each axis you can compare against a single radius. Sphere collisions are
invariant against rotation, which is why they're also highly applicable in this case. Taking the centre point and using a bounding box on the other hand isn't, but its still can be an effective optimization, and using centre points helps with the approximation anyway in a context that can rotate. (i.e. A box rotating around a centre point is probably a lot more useful hitbox approximation than a box rotating around its corner.)
Now there's also the question of whether when things are rotating you actually do want rectangular hitboxes, and when they're rotated, you want collision between those rotated shapes... that gets a lot more complicated. If both boxes have the same rotation, no problem, just do the original calculation in the space you had before the rotation. If one is rotated and the other isn't, you're now basically in the realm of colliding
arbitrary convex polygons. I won't get into how to do that, but I'll just say that it's pretty difficult without an efficient multiply. That's the difference between an "axis aligned bounding box" (AABB) and boxes that can freely rotate.
Very often engines will do a sphere test or and AABB test with a shape that is large enough to encompass an entire object as a fast first step to check for potential collisions (with false positives) before doing more expensive collision tests to see where/if they actually collided. This presupposes that you want to do a more complicated collision than that first step, though.
At a higher level still, you might also have some sort of
space partitioning tree or other structure to accelerate figuring out which objects are near another to collide. Not really important when you have a low number of objects but when there's a lot of stuff around, narrowing down that list of things that you have to check against each other for collision can reduce the workload by an order of magnitude. (Depends on how much work you have to begin with, whether it will pay off.)
edit: tepples points out below that sphere tests might be fairly efficiently implemented on 6502
The flaw is, all things now must have the same size collision box, I think this is how Contra does it, from memory I think everything you can shoot is the same size as the player for the most part. If you need different sizes you could shrink the "box" and then make a player say 4 points, and a pickup 1 point, and a large enemy 8 or 6 or 12 points etc.