Let me say up front that I really dislike the Slack app, but I do think this comment is unfair on Slack.
For them, the biggest lever to improved user experience is almost certainly _product features_ not performance or native integration.
As much as I'd like drag and drop support or less RAM usage, Slack are mostly trying to convert people who have never used instant messaging in the workplace to using it daily (which I think is overall a win), and mostly trying to make users who are not as comfortable with software as we are use a new piece of software.
As an example, when I share a Google Docs link in Slack, I get a prompt from Google Docs _in Slack_ with a one click button to "fix" sharing so that those in the channel will be able to see it. That feature is probably vastly more impactful than improving system integration.
For there to be features like that, or an ecosystem of third party integrations, speed of development is likely a huge factor, and for that, being able to share the codebase across web and desktop apps is likely a no-brainer.
As much as I'd love to see a more performant Slack, it's likely that it would have large negative impacts on the speed of iteration elsewhere, and so I can understand why they don't do it.
Yes there are faster Electron apps, but typically they manage that by... not being Electron apps in certain areas, and sacrificing adaptability for that.
Also, Slack doesn't change _that_ much right?! Well yes and no. As an end user we probably only get ~10% of the changes – 90% may be experiments that never see the light of day but still have to be built in order to find the 10% that are worth it. And even then, assuming the new features are only designed for ~50% of users, because users don't typically use every feature of a product, you'll only actually see 1 in 20 changes that the Slack team build.