Just an update.
After some years, since I had some spare time (ugh!), I decided to update the MyCloud firmware from version 4.00.01-623 to version 4.05.00-320 (latest one as of now, April 2018), because it brings a lot of security updates. I did this after verifying that nothing had changed in the process required to install custom packages. The latest GPL source code version published on WD website is for firmware version 4.04.03-113, which was published in 2016, so quite old (I already wrote to WD to request them to publish the latest firmware source code), but it’s already containing the My Cloud OS 3, which seems to be the latest one available (according to the firmware release notes), so I was confident enough that nothing disrupting was brought on by WD with regards to custom package building.
Comparing the two source code bundles, I see that WD has fixed some scripts, but in general all I wrote in the original guide + the patched scripts I provided here are still 100% valid to build custom packages. The only “strange” part is that they commented out the following row in build-armhf-package.sh:
##export DEB_CFLAGS_APPEND='-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE'
I don’t know what could be the implications, anyway in my virtual machine I use to cross-compile packages I left that row because it never hurt. Maybe anyone here with more experience can shred some light on this?
Anyway, the upgrade process went well, although with a huge amount of panic… The first reboot after firmware update took all night long (!!!), with the white solid led being on during this process and the WD My Cloud web UI leading to an almost blank page (with no login prompt) and no way to access the device (no SSH, no Samba, etc.). Since a lot of disk activity was in progress, I left it there overnight, although I already made many research on the Internet and started to think I had to unbrick it in some complicated way 
Next morning, the led had turned blue, so I had new hope! SSH access was not refused any more (although the connection was hanging before requesting the login prompt) and the web UI was keeping the browser connected rather than just spit an almost blank page. Long story short, after about 8 more hours, I was able to access my device again (SSH, web UI and Samba shares) and all seems to be fine. I still have to reinstall my custom-built packages (meanwhile, I built some updated ones because security updates have been published by Debian), but I feel good now. There are some “find” processes still running on the WD My Cloud which seems to be adjusting permissions on the whole /shares/ folder (and this explains why it takes so much time, I have a lot of data in this unit).
Anyway, there’s a severe design flaw in the software WD is providing for this device, it’s unacceptable that a firmware upgrade brings your unit offline for almost an entire day, with around 8 hours just to complete the first reboot. And what if a power outage occurred meanwhile? Fortunately, I have an UPS… but hey, this is a consumer product and I think that any common user would have at least tried to switch the unit off/on and/or to reset it to try to make it respond again… and I can’t imagine what could have happened…
So, be VERY patient when you do a firmware upgrade.
On a side note: some built-in packages provided by WD (like rsync) are not really updated with all the security fixes provided by Debian. For instance, the provided rsync package is still at version 3.0.9-4, while for wheezy the latest available version is 3.0.9-4+deb7u2, containing security fixes. This is one more reason to learn how to build and install packages, although it’s not that simple for common users.
(by the way, for rsync specifically I suggest to build the latest version from jessie repository).
