No, it's not well-engineered (speaking with over 25 years as a professional software engineer), at least the portions of the code I have looked at. Things I vaguely remember (it's been ten years since I looked at it) are lack of data normalization (and not in a performance optimizing way), template includes that depend directly on order of inclusion and variables in other templates, very little code isolation, and PHP.
WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.
By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.
See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more details on PHP.
One excerpt from that page:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
@fopen('http://example.com/not-existing-file', 'r');
What will it do?
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.