Legally, even taking the whole "copyright infringement equals theft" attitude at face value, it's not, because WordPress is GPL and GPL explicitly forbids adding new restrictive terms to the license, and also forbids combining it with more restrictively licensed code. In fact, in the past, Automattic did to Envato what they did to WP Engine specifically because Envato had taken the position that nulled plugins are infringing.
Of course, Automattic is now suing Festingervault for hosting nulled plugins, because Matt Mullenweg doesn't have principles, he has emotions.
While there are some cases in which two GPL programs could be said to live in the same address space[1] (or PHP interpreter), WordPress plugins are very much designed to integrate with WordPress and modify its behavior. From a copyright perspective, that smells awfully like a derivative work, and thus all the usual GPL licensing language and copyleft would apply here. Ergo, I'm writing these opinions under the assumption that WordPress plugins have to also be GPL.
[0] For example, they consider proxying out to a separate network service to not escape the bounds of a GPL "Program".
[1] It's very rare nowadays to see separate programs live in the same address space. Classic Mac OS did this; but I don't think anyone is going to take someone to court over retrocomputing hobbyist software. Linus argues that you can have proprietary kernel modules as long as they only touch user-mode API stuff, but that's because they have a specific licensing exception that makes the UAPI outside the bounds of the GPL copyleft. The web is the only place where you could have GPL Programs coexist within the same isolation boundary.
However, some plugins are distributed with a "split license", the php that integrated with WordPress is GPLd, but JavaScript, css, other assets are under a different license. [1] I don't think this has been tested in court one way or another. Matt of course considers this heresy [2]
[0] https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
[1] https://www.contentpowered.com/blog/wordpress-plugins-free-g...
[2] https://ma.tt/2015/07/licenses-going-dutch/?utm_source=perpl...
Given that reimplementing an API for interoperability is at least sometimes not a violation of copyright (see, e.g., Oracle v. Google), using a datastructure defined in a piece of software providing a plugin API to interoperate with it cannot make the resulting software exist only as a combination with the software providing the API, since it relies only on some software providing the same API, not necessarily the particular software that originally provided the API.
Specifically running something as basic as register_activation_hook() means you're linking with WP-provided code.