CPU/memory performance aside, I saw somebody bring up the Boston areas....
All of the city areas in FO4 are woefully unoptimized. Well... that's not fair. They are just poorly optimized. Basically, all of the static objects in a given cell are combined into one big monster mesh. If it's not going to move or react to collision other than blocking actors/projectiles/dynamic objects, then it's more efficient to combine the meshes. Every individual mesh constitutes at least one extra drawcall... and realistically, several more, because each shader/material property adds another pass that your CPU must specify - and even FO4 uses things like shadow maps, normal bumpmaps, specular maps, etc. So each mesh you combine into one chunk, saves several drawcalls. When you have hundreds or thousands of meshes, you can cut down 4-5 digit amounts of drawcalls to ultimately produce the same thing by combining as many as you can into one. Thing is, they didn't do a great job dividing up the actual cells in the region for that, so it's always dealing with too many vertices. It's tied to how the game decides what to render, and what doesn't need rendering. The creation engine uses occlusion culling to work this out. Essentially, occlusion data from those big monster meshes, factored against player orientation, determine what parts of the mesh actually get the textures drawn on, have shaders applied, etc.
The issue is, a lot of the cells with these precombined 'master' meshes are simply too big, or shaped in a way where you will just be triggering double, triple, even quadruple the drawcalls of any other area. A big part of the problem is how the game decides when to apply occlusion culling - it wastes a lot of resources drawing things you can't actually see because it doesn't start culling until you are fairly close to an occluding object. Becomes a huge problem when you're in a city PACKED full of polygons and high-altitude points, especially when those cells are chonkin. Say you're standing on a tall building, looking on at rows of tall buildings out on the ground below. From your position, a lot of what's on the ground behind those buildings is blocked by them... but most of it is still being rendered. And a big part of why it does that, is because they're in the same cell, and it's thusly still tracking the occlusion data for all of that stuff over there same as anything in your immediate vicinity. On the ground, it's marginally better because there are enough objects in front of you to stop objects from rendering as far back in the cell. But you STILL almost have to be staring straight at a very close wall for the engine to stop caring what's behind it in some cases. Till then, it may still be fumbling around with geometry and shaders back behind it. To compound it further, there are still points where too many big cells converge, creating these death zones in the city where drawcalls spike even more as it begins to map textures to the polygons of multiple huge cells concurrently. You also run into points where you are rapidly entering and leaving multiple cells, forcing a lot of stuff to load and unload, bringing storage bottlenecks into the equation. We are talkin exponential increases in resource demands on multiple fronts. Even if your GPU could easily handle the massive amounts of drawcalls (which I think the best ones easily could,) I doubt any CPU out there can give that many quickly enough to keep everything feeding smoothly.
And understand ONE thing about drawcalls. They're CPU intensive, as they are when the CPU tells the GPU what to draw. Modern games, with all of their complexity, environmental destruction, dynamic meshes... very rarely surpass 5000 drawcalls. Hell, some of them don't even pass 1000! Maybe when they were still working on the game, pre-optimization it did 5-6000. Meanwhile, FO4's Boston hits 5 digits in some places. 5-digit drawcalls are a horrendous thing, and FO4 has no excuse for it. There are better looking, more intricate games sitting right next to it that don't use half the drawcalls FO4 does in its lightest areas. I just really want to emphasize how cavalier the game truly is when it comes to what it expects from a CPU - it's often more than double what any decently-optimized game could ever require. Actual orders of magnitude more than just about any open world game you could think to name. It's utter insanity. No matter what hardware you have, it will always underperform to some degree, because what it wants CPUs to chew through in dense areas is idiotically high, like Bethesda was when they put it out in this state.
We could talk more about the cell system too. The entire map is split in to cells that basically determine how/when to actively stream in what objects/textures, versus what will just be 2d (or false-3D) LODs from pregenerated billboard textures. It also determines when scripted things actually run. FO4 is a bit odd in that it keeps track of MANY more scripted variables than most other games. These variables pertain to things like where each NPC is in the game at such and such time of whichever particular day or point in the game, what they're doing, quest states, radiant/emergent events scattered everywhere across the map. And as you play, it must track more. When you are far enough away from any object bound by the states of these variables, they stop being 'active' in the sense that the game will not calculate what they are doing in each frame - instead, it will run a 'fast-track' script simulating all of the things that would've happened in the time before you got close enough to make them active again. A lot of them get resolved in the loading screens. But for things closer, the game is calculating every step every enemy and NPC makes, one frame at a time. This alone can actually lag your game - too many scripted mods cause the script system to queue, which forces the render pipeline to slow to however many frames it can process per second. No amount of CPU power fixes that, the scripting system has a a finite amount of things it can handle in one frame before it has to start dragging them out and racking up tasks. The speed it goes at is frametime-limited, never requiring much actual power to work - but no way around the time it takes to complete sequences of tasks. The city is very 'busy' and shows the weaknesses in Bethesda's methods. It goes by cells - the game will keep all of the dynamic script-related things within a circle of proximal cells active. And there's more of that in downtown than anywhere else in the game, by a whooolllleeee lot. You can actually change how many cells it extends out to, but increasing or decreasing it will desync scripts and depending on where/how you travel, can break your game about as badly as it can be broken.
Boston is notoriously bad. It's been everyone's problem for years, with a lot said about how/why, but not many great solutions. There was a time when the BEST possible configs still couldn't take you much over 30FPS in parts of it. And yeah, CPU does have a lot to do with it. The lag spike comes from dealing with say... 5000 drawcalls max for a given frame to say... 20 or 30 thousand. And then you factor in the amount of script actors/flags present in the area. Yeah, it's a CPU killer. It's also worth noting, FO4 is very poorly optimized for MT performance, so utilization is bad on those. The memory optimization is equally poor. You may actually look into downloading ENB. Even if you're not going to use the effects, it has a memory fix that you can set up, which helps significantly with overall stream-loading performance. Faster, higher bandwidth memory probably helps for the same reason. ENB just changes the allocations around, lets you better match how much RAM gets used for each MB of VRAM. It tries to make the game use your available VRAM more effectively. Similarly, any mods that reduce memory load, such as optimized textures, help a lot. Another big performance killer on the same front as the things I'm talking about... is grass. Reduce grass density/distance, and you can easily gain dozens of frames in really heavy areas. Grass eats drawcalls and memory for breakfast in FO4. Maybe that's the grass they were smoking when they put together this busted optimization.
As far as I know, there's no concrete fix for that kind of lag, though. The engine really is just that terribly inefficient, in its bones. It has a blood disorder from bad bone marrow. Pretty much every system has SOME hiccup with it. The engine really wasn't built out to handle the upped polygon/cript counts of FO4. They majorly overexerted it, and then took the fastest possible route to optimizing it just well enough. The whole thing needs a major overhaul before it can ever hope to run well imo. Getting high FPS absolutely everywhere is gonna take some modding. And the thing is... if you change any static objects in a cell, you break that precombined optimization and draw calls can easily get over 40k, at which point you might just get medusa'd. It has to be reconstructed manually after changes are made. So it would be a very tedious job for a modder to fully fix. Especially since any other mods changing the area break it again, and whole new precombined meshes need to be made for every possible combo of worldspace-altering mods. Over the years, modders have focused heavily on learning to change things without messing with them in the first place. You can break your whole save just by going to the in-game console and deleting the wrong tree... disabling that optimization for that whole area and causing unstable behavior that corrupts savedata. I'm tellin you man! Shit's mad busted. Icarus'd the crap outta that thing. She's a lil scorched up from that trip to the sun they took when they designed downtown boston.
EDIT: Something very important I forgot to mention: try installing F4SE. It's harmless and completely reversible. What it's really meant to do, is add functions to the engine's scripting system, but it also beefs the whole thing up so that it can handle more scripts, as you would need for modding. IIRC, vanilla FO4 has scripting issues, and there are cases where scripts don't resolve correctly, causing save bloat. The unresolved data hogs headroom, which can become an issue in places like boston. You'll notice increasing lag over time, and load times go wayy up, to the point where it will start hanging on load. Maybe you do some quest, or fast-travel between a certain sequence of locations... and from then on your game runs like garbage. F4SE makes it a lot harder for vanilla to get overburdened with script junk. There are also plugins for F4SE that streamline it and make it even more powerful in various ways, too. It's not only for installing advanced mods. You can use it to make the game run better, too. Though the unofficial patch mod corrects a lot of scripting errors that cause slowdown in the vanilla game to begin with.
@evelynmarie made some great suggestions to raise the performance floor so that even the worst-performing areas at least perform at their best. Like, I personally can at least get over 60FPS in Boston with a 3900x and a 3060ti. And that's with visual mods. But I also have all of the optimization mods running, tweaked memory performance, changed how draw distance works in the ini (there are texture/mip related settings that aren't covered by 'draw distance' settings,) all sorts of balancing of different render relating settings, F4SE performance plugins, so on. But I DID have to pick at it from different angles over a very long time, and I still don't know what exactly makes it run decently on my setup.
If what I'm saying is true, it's quite unbalanced. So much so they couldn't even squeeze in a way to reasonably fake the generally beneficial trees. To be a fly on the ceiling of the braincases of the people who planned this. The grasp of asset and feature scaling is nonsensical to me. And that goes far beyond the trees or the forest.