Hi 2c86a546f0e5, it's something we want to build and it remains in the longer term backlog, but there are no immediate plans to work on this. The investment required is unexpectedly high and to date other initiatives have been prioritised above this https://www.atlassian.com/roadmap/cloud?selectedProduct=jsw&. I apologise for the frustration and inconvenience this has caused.
Regards, Eoin

2c86a546f0e5 +1 on all that you wrote. 

So this has been known and tracked since 2019 and still not fixed - come on Atlassian!!
From my own experience working with software, I'd say we've all spend much much more time talking about this problem (and it's drawbacks) than Atlassian have spend on actually fixing it.  

I find it hard to believe it's immensely difficult to find and display the subtasks connected to parent issuetypes with a certain sprint assigned to it during various lookups, even though the subtasks themselves lack the sprint information directly. 
Hint: look on how you implemented 'Group by - Subtasks' in TMP sprint board - all subtasks are found just fine there.     

eryan / anyone,

• is there any update on this please? It's blocking a High Priority Bug JSWCLOUD-26933 (and now JSWCLOUD-26207)
• Scrum board not functioning as expected rendering it unusable for our team.

Could you help answer as well, looking at the History:

• why was this not a bug any more?  but flipped to "Suggestion" from a "Bug" in year 2022.
• why was this priority lowered from High in year 2022. (when this bug / same issue was tracked from 2019)

Hi team. Any update on this?

Hi eryan.  What's the priority of this issue? It blocks JSWCLOUD-26933 which is an inconsistent behavior with Kanban board. This ticket is definitely a bug and not a suggestion.
We just switched from Kanban to Sprints and I noticed this significant inconvenience. We have been using sub-tasks a lot while in Kanban since they were showing there just fine.
More of my issue is described here 

are there any updates on this issue?

Hector, this used to be a Bug. They reclassified it at one point, which met with objections here. Still no solution. This has been on the books for years—since they introduced the new project format (and renamed it multiple times).

Please note that this (JRACLOUD-81069) is not really a suggestion - it's an important missing feature. I would rather classify it as a bug since filtering by Sprint does show Subtasks when in a company-managed project - same filtering user interface, different project type. Unless that was done by design trying to produce a lighter version of the company-managed project type in the team-managed project type.

A consequence of this issue is that even though a recommended practice is to break user stories (deliverable) into subtasks (means to deliver a story), managers refuse to use subtasks because they can’t report on them. So, instead, they recur to use Epics as User Stories, and issues of type Task as subtasks, but that creates a distorted backlog size, and the concept of Epic gets distorted too.

For example, if the backlog could have been 10 user stories, it becomes a much larger size if those 10 stories are broken into issues of type Task, thus making the backlog look much larger to leadership.

https://getsupport.atlassian.com/browse/JST-955717