It's not LWCs, actually, but rather Locker Service that's causing the problem.
I created a pure LWCs as a baseline without Locker Service interfering.
This runs in a fraction of a second, much less than 10 seconds or more; the page may take a second or two to compile the code, but the actual page execution is incredibly quick.
This has been a known issue since pretty much the beginning of Locker Service (API v40.0).
You can avoid this problem by making sure the data isn't proxied. This can mean either copying the data beforehand (this.data = [...data]), or passing in a single JSON string and then parsing it in connectedCallback() or a setter method, depending on if you need reactivity (see example in the second link, above).
The "under the hood" problem is that the entire array has to pass through a filter callback every time you use an index operator, so 3,000 elements become at least 9,000,000 callbacks, which... well, you can see the result. Once you copy the data out so it's no longer caught in this filter trap, everything runs blazingly fast.
I've heard that salesforce.com is aware of the problem, but we don't yet have a timeline for a fix. Stay tuned.
Note: LWCS is basically used to create, update, read and delete a record without any using Apex Code. Similarly, LWC can also leverage LDS by accessing data and metadata from all Standard and Custom objects.
