It depends on the kind of game you're working on, but arguably if you're working on anything ambitious then you can't do it. Yes you can scrape by doing pointless heavy updates every frame for only 100 objects in the entire game world.
The moment you want to simulate something more interesting these walls will be hit and it will directly affect your design process though (design is ongoing as the game is built!). So if you want to be a better game developer, develop in ways that you'll hit these walls less often and limit you less.
Those updates don't need to be heavy if nothing is happening.
And as I related elsewhere, with a Ruby-based game engine it took 1000+ objects being updated every frame alongside other heavy stuff (multi-voice waveform based on-the-fly sound-synthesis, in Ruby) and actually passing each of them to the renderer, before I needed to bother to add any filtering.
And then when I did need to it was a trivial change to filter the list of objects to update. To the point where I literally just currently naively every frame does a map over every object in the level and check if they're within the viewport before doing the update.
Yes, you will sooner or later hit limits, but 1) you're likely to hit them later than you think, 2) it doesn't matter because when you do hit them you're likely to have a good idea of what characteristics to filter them by. E.g. for some games you want to update, but not render, objects outside the viewport in many situations based on other measures - e.g. Minecraft-style simulation of mobs within a certain distance of the player; for other games once an object is off-screen it can cease to exist instantly. But it takes consideration, and you might as well defer that consideration until you need to, because it's orthogonal to the actual update.
And it's easy-ish to go from calling update on everything to moving objects in or out of a "currently visible or at least close enough that we bother simulating them and may need updates" bucket (which might be what's on screen, or what's in a room, or in a level, or within X amount of distance, or any number of other things) at whatever granularity you need to get the performance you want.
The general advice of splitting the updates into frame-sized chunks solves the important beginner issue, and the performance tweak of reducing the number of objects you update is something you'll likely encounter much later.
E.g. I'm currently doing a simple platformer with my son for fun, and just a very crude "is any part of this objects default starting position within x distance from what is currently on screen" is more than sufficient to constrain the update. Before that I just had it even naively render every single object in a level, because it was fast enough, so I didn't bother filtering anything. I only needed to start thinking about performance in the first place because of a combination of me going over-board with various effects and a fully waveform-based software synth and this all being written in Ruby (using the DragonRuby game toolkit [1]). If it'd been written in a faster, compiled language, or I'd been more reasonable in my expectations we'd likely never have needed to think about it. But 10+ parallax layers, wave-formed bases synthesis, and a bunch of pixel effects might be nothing in C, but keeping 60 FPS in Ruby that way takes a little bit of care. That said, we got to 1000+ objects updated every frame before I needed any filtering at all.
I'm sure we'll eventually do more - not all objects have any animations or move, so they'd be easy to filter out too, but then I have to ensure every type of object is categorized accordingly, so I won't bother doing that until there's a need to, and it takes calling an update or render method that does nothing for a lot of objects before it starts dragging down the frame rate.
It's ok to criticise, but it's more useful to suggest better alternatives. How would you optimise this? Only update objects in view or within a certain distance of the player?
If you update every object - every frame - that's a lot of wasted updates for things that don't need to update for various reasons.