You have two very different things to manage:
The server must manage the entire world, in an authorative manner. For that, communication with N clients (where N is "massive") is necessary.
The client could, in principle, know about the entire world, but it needs not. For the client, it is sufficient to know about what's nearby the player. Assuming for example a rather coarse grid-like partitioning, it would need to know only the player's cell and the 26 cells around the player (or 8 cells in case you have a 2D grid). A somewhat finer grid is better, but you get the idea.
Now, a lot of pickups, what is "a lot"? You dig maybe 5 things per second, that's maybe two dozen numbers that need to be updated on the server, and the server may have to transmit those to some other player whose area of interest overlaps your cell. For a computer, this is quite ridiculous amount of data, and a neglegible amount of computation. It may become a challenge when there's hundreds/thousand of players in the same cell (then your paritioning is too coarse).
The server does not need to know, nor care about the rotation of the pickups or such details. Why would it?
The client actually doesn't care either, since this is just eye candy that the client can make up on the fly.
What's necessary from the server's point of view is knowing that you were digging at (30, 40, 50) in the node you're in, and it decides that this spawns e.g. three objects of type 5, or one object of type 7 with a count of 3. That's all it cares about, and it's all it tells you. It will also include that information in the data sent to someone moving his area of interest over the grid cell later (assuming it's still there by then).
The client gets told three objects spawned there, blah blah. Now, whether the client displays an ASCII-art map where there's now a 'D' or whether it shows a rotating pile of dirt, it's all the same. Whether the piles have different rotations or whether only the ones close to your player rotate is all the same, too. It's just stuff that is displayed on your monitor, it doesn't affect anyone else.
So, in the concrete case that you want to rotate only nearby piles of dirt, you can just do a range check on all the objects you know about. Since the data set isn't large, even brute force on everything will work.
You can (and should) depending on your partitioning size, trivially prune away grid cells that are too far away.
You can, of course, furher sub-partition your cell and use something super smart. Use a kd-Tree if you will, but do not expect huge gains. You can prune stuff away with Manhattan distace, or your can sort your stuff in a small grid of your own... but why?
A distance check (really squared distance, but it's the same to you) is a mere two multiplications and an addition (optimized to MUL, MADD, so really just two operations), followed by a branch or conditional move. That's pretty much as fast as any other operation which doesn't prune entire grid cells at a time. In fact, this is something that you could even do on the GPU...
Seeing how you will have a few hundred, or at most a few thousand distance checks against the same position (squared distance works fine), you really don't have much trouble just doing that calculation, even more so as it's a rather cache-friendly iteration over contiguous memory, and with conditional moves, it's dirt cheap. Something like (pseudocode)
rot = r[i] + 1; r[i] = ((dx*dx+dy*dy) < DIST_SQ) ? rot : r[i];. That's one iteration over an array of a few hundred values per frame. The computer couldn't care less about doing that, it's contiguous loads and stores, simple ALU, no branches, and only a few thousand iterations.
This (many-to-one) is not the same class of problem (many-to-many) as on the server. Really, the client isn't the problem.