I’ve noticed this pattern numerous times, my guess is service/feature teams want to avoid at all costs taking another service dependency (and all the testing and coordination that entails) so they just punt.
Sometimes a big old RDBMS housing all of your data which is actually already related in reality makes the most sense.
Like all retail bigcorps, I assume that IKEA has lots of internal systems, half self-cooked, half based on SAP or Oracle or whatnot, that together form the entireity of their operations. These formed long before "microservices" were hip and trendy and will be around long after the hype has died away. The webshop is a part of all that and it must be closely connected to the rest of the IT in lots and lots of places.
So, what you're suggesting is "IKEA should just rebuild their entire product, sales, supply&demand, logistics and finance IT from scratch in a single monolith on a single database". That'd be a fine end-result indeed, but unachievable on any timescale.
It’s better to have such a poorly working illusion of a single db than to have no such illusion at all which means having to log in multiple times etc.
I think there's a middle ground between microservices and a single monolith for a large global corporation.
Which is all fun and games until some intern gets asked to add a 'most popular' sort to the search page. He quickly figures out where the 'OrderProduct' table is, throws in a quick count and a group-by to the search query and the whole site gets taken down by it.
Of course I take your point but there is somewhere between everything in one monolithic DB and every bit of data has its own microservice. It needs good judgement to divide it appropriately.
That I know the store won't do. But then, if they are so large that it's a crisis, they have no excuse, and if they are small enough to have an excuse, they quickly revert to the last version and try to discover what went wrong.