Well, to be honest, I'm not entirely sure how it ever worked, though clearly it did work...
With binary-only packages there is always the problem that they need external libraries. None of this is documented or supported by Spotify, and the distros (including our SBo maintainer) need to reverse-engineer the right setup. Through no fault of their own, all the distros have horrible problems with this because they are forced to guess (e.g. look at the Arch AUR page for spotify, and the traumatised ubuntistas in the Spotify forums). And it appears that Spotify have lost interest in updating the Linux desktop client but can't be honest enough to announce it or answer questions about it. And this is why we hate corporate closed-source software, even if Spotify likes to present itself as cuddly and different.
Anyway, the spotify client uses libcrypto/libssl and libnss3, which have both had important security updates since Spotify built the client binary. The SlackBuild assists the binary to find those libraries by creating symlinks in /opt/spotify/spotify-client. However, libcrypto/libssl were symlinked from /usr/lib64, but the correct location is /lib64, and so the symlinks were broken. I don't know when or if /usr/lib64 was ever correct, but /lib64 is correct now. As a second problem, symlinks are apparently also needed in /opt/spotify/spotify-client/Data, but were not provided by the SlackBuild. It's a tempting conclusion that something changed when openssl-solibs and seamonkey-solibs were updated earlier this year that prevents the SlackBuild's original setup from working, but it would be difficult to reconstruct how things were last year without a lot of work. And if spotify works now, what would be the point?