We may never know exactly why the Cobi app never lived up to it’s potential. But I’ve been in the software business long enough to know that it is almost always due to compromises and decisions made around which product lines get the funding and support. This is even more of a problem when you take a system (like cobi.bike) that is acquired from another company or open source system, and integrate it into your own ecosystem. That is often hard, tedious work and generally while that happens you do 0 feature work (because new features = new bugs) and just try to get s*it working. Meanwhile other teams can just keep developing new features and fixing existing bugs. So the migrated system usually falls behind, and by then time you launch it to hit whatever arbitrary deadline was set by management, you almost always have fewer features and more bugs than you like.
Software development (indeed most complex projects) generally have limitations on quality, time, and cost and getting a project done while hitting all three is VERY hard, even for the best companies in the world: “Good, fast, cheap. Choose two.” In most large companies (especially more old-school ones like Bosch) “fast” and “cheap” are always the things that picked.
My guess is this isn’t some evil plot to extort money from users by creating a purposefully bad product. It’s just a product line that likely ran out of time or out of budget, got shipped with incomplete features, and ended up not selling very well. So it likely didn’t get much extra funding or resources for further development of features, which probably depressed sales further. Meanwhile the other product lines sales obviously continued to do well, and at some point the decision was made to put the SPH out to pasture and focus on the products that are actually making money.