I have been working with Magento CE 1.x for several years now. I have spent at least a hundred hours inside the debugger carefully stepping through the seventy layers of its core code to make sense of it. I can list a lot of problems I have seen in it. However, I cannot recommend any alternatives: I refuse to touch WordPress because it's WordPress, I have no intention of using OpenCart because I have already tried it once and its author is a crazy man, and I have no experience with Shopify or Prestashop.
Business issues:
* Magento is in control of your price structure. You will structure your prices in the way that Magento allows, or you will suffer. Our client was not happy with the price calculation, so we spent hundreds of hours changing it thoroughly. Do you want tier prices for product options? Too bad. Do you want customer group prices for product options? Too bad. Do you want to set discount values as "discount this much after applying all taxes" (e.g. because your shop displays only prices after tax)? Too bad, all you can do is "discount this value on the untaxed price, plus whatever reduction that makes on taxes" or "calculate the discount amount off the taxed price, then discount that much off the untaxed price". And once you have made some price customizations, the customer will find an extension that does something to the prices and breaks your changes in a creative, subtle, and unexpected way.
* The CMS part of Community Edition is a joke without a punchline. It doesn't even have any menu module, only the ability to manage pages with content dumped in an RTE.
* Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousand hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and they're still asking for more. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then.
Technical issues:
* The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse the MySQL error message to identify the duplicated fields/values and delete the duplicate rows silently. You will get your index, but you might no longer have all your data. [0]
* The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This magic is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data.
* EAV models. In theory, a workable idea, and you can even make your own EAV models if needed. In practice, you need to spend a lot of time in the debugger stepping through the code to figure out what code in the Product or Customer classes needs to be copied into your custom EAV model to make it work right, because the core EAV model doesn't have half the needed functionality.
* Misleading code comments and annotations. Nothing like finding a method whose phpdoc says it returns a class that does not exist in the codebase.
* XML configuration jungle:
* Module configuration and theming configuration is based on heaps of XML that has no schema. Module configuration combines XML documents in the "there can be only one" manner (if two documents have XML nodes with the same path, the second one's value overwrites the first one), specifically so modules can change each other's configuration.
* Theming layer operates on "blocks", which are basically a PHP class with a corresponding .phtml template file. These blocks are defined, managed, and composed through XML files. You can even encode instructions like "after creating this block, call its method foo()" in the XML. If your theming doesn't seem to take effect, you get to step through the loader to figure it if it's not loading your file, if some file loaded later is giving different instructions, or if you placed your code in the wrong place in the XML structure. Or if there's some extra XML configuration in the database specifically for this category/product/CMS page. Happy hunting!
* Using third-party modules and themes is a russian roulette:
* Magento includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. However, lots of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code.
* Some modules are well written, some do crazy things completely at odds with Magento workflow (e.g. an extension to set custom tier prices that calculates them when you load the product from the DB and ignores the precomputed price index in the DB), some are downright broken. And some of them contain gaping security holes – are you going to audit all the third-party code you include [4]?
* Magento core JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies of jQuery and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't. I have seen a page that loaded Prototype, ExtJS, jQuery, and Angular side by side.
* As with every extendable system, some extensions don't work well together. Every module has the ability to override a Magento core class. Fun happens when two different modules want to override the same core class.
* Other
* Performance is demanding. You need powerful hardware and good caching to get good performance. And then you'll get that one extension that tanks your performance, like the Analytics plugin that loads each product in a category individually to send its data to Analytics when you view the category page.
* Security updates are fun. When you log into the admin panel, you will see a notification about a new security update. This notification shows up because a scheduled task periodically fetches a news feed, which contains security alerts, new version announcements, marketing spam, and whatever else Magento wants to show you. You read the notification, and follow a link to the Magento downloads page. There, after logging in, you can find and download a .sh file which contains both the patcher and the patch content itself. Run it to apply the patch. If the security issue is critical enough, Magento will publish a repeated reminder to apply it a few days later. Which your news feed will again pick up and dutifully display to you, despite the fact that you've already applied that patch. You will also get a panicked call from the client because he logged into the backend and saw that message too.
* Some things are just silly:
* Translation manager cannot cache the translations correctly, you get different translations for the same input with caching enabled and disabled.
* One class has both escapeUrl() and urlEncode() methods, and neither of them actually does URL encoding.
[0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[2]: https://imgur.com/RMxWEgR
[3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[4]: https://news.ycombinator.com/item?id=13100162