Rather than post a reply to a thread I will start one here. It's always best to be at the top of the page. Never read the comments.
Not everything that someone else types into a little rectangle deserves a reply, even if you have one handy. Networks that are optimized for engagement always bias towards inflammatory posts that trigger replies, you're just feeding the beast if you take the bait there.
But, some things should be said, even if not directly in reply to the thing that prompted them. Let's go through it in order.
On the current state of AI: A surprising number of mature products are returning AI-generated results, with something between terrible and hilarious results. Amazon's recommendation agent badly summarizes user-generated content, Google's search engine promotes goofy text from normally reliable sources as if it were correct, and more. It's a full-on Gish Gallop where machines can spew out nonsense faster than we can correct it.
On nostalgia for the "small web", the "old web": A few of us remember when the net was different. It was a lot slower, a lot more expensive to use and to operate, and the public web was tiny by modern standards. There was a culture which was kept in check by acceptable use policies that threatened you with banishment if you went beyond them. That old web barely exists now in little pockets where it hasn't been overrun. If you weren't there for that, I'm sorry. But don't criticize people who go out of their way to recreate that experience, even at great personal expense, because it was really different and not like the net we have now.
On internal communications within organizations: an incredible amount of useful information gets produced in the course of people interacting online and responding to questions from their peers. Even the best of intentions does not turn that ongoing conversation into reusable artifacts without a bunch of work. The problem is compounded by ever-changing organizational structures that do not map neatly to well-known names of things or existing external knowledge. I do know that when a well-understood task is carefully documented for external use that it can be incredibly helpful for transfer of knowledge. Unfortunately the questions come so thick and fast that there's also tendency to assert that the customer could and should do something complicated that we barely understand ourselves how to do in a repeatable fashion.
On complexity: I have seen one too many architectural diagrams where a complex system is built out of complex parts to solve what should be a simple problem. Better yet all of the complex parts come from the same vendor, so that in order to understand what the system is doing you need to commit to deep knowledge of that single vendor's product space. Contributing to these sorts of projects is very difficult as a lot of the necessary knowledge is in-house in the vendor and often the scale of the solution is well beyond the single computer or home lab to prototype a design. Big-budget complexity doesn't look more likely to succeed on its technical merits, but it might have a better business reason for existing because there's money to be made when your customers have to be all-in on your products.
(OK enough ranting for now. Some fragments of this might get cut and pasted into smaller rectangles.)
