I guess my position is that we should assume our software engineers are professionals who are properly motivated to succeed, and with this in mind, we should take a priority-based, Kanban-style approach to building and deploying software, with significantly less emphasis on estimation and significantly more emphasis on prioritisation. I don't think anything I do is novel or special; it's just not widely adopted as far as I know.
I've been using a backlog-driven, priority-based approach in my own practice for the last 5+ years, which has been extremely successful at delivering products, but remarkably less successful politically. Non-technical management seems to have come to the conclusion that we ought to be able to accurately estimate the time it will take to build stuff, despite decades of evidence to the contrary. Loads of people argue that this is the "only way" but the processes commonly implemented are more about making management feel good than about actually getting work done. Unfortunately, I've found that making management feel good is often more important than actually doing the work.
All of that said, what I suggest is very boring: instead of spending the (significant) time estimating the effort required to implement each task, instead you should spend the time working with the client on prioritising the features, and internally spend time prioritising the decomposed tasks. What features/tasks absolutely must be ready by the deadline, and what can they live without? Can some features be shipped "incomplete" from your perspective? For example, can you deliver a veneer over a manual process on launch day, and automate the process later? If, upon inspection, a feature turns out to be extremely complex and time consuming, can it be re-prioritised? Can you spend time working on reducing the total amount of actual effort that's on the "critical path" to the deadline? Obviously some things just need to be done, but when you drill down you often find that a lot of time is spend on features and tasks that are not critical (by whatever definition you choose to use).
The idea is simply to make sure that the important stuff gets done first, so that you are in a position to launch as soon as possible. You can and should continue to work on the project after the launch day. This approach has many well-known carry-over benefits like the ability to start user and automated testing very early. Unfortunately, as mentioned, this can be very tricky to pull off politically, which I think is why it's not more common.
Once you get to this point then reporting upwards should be about features delivered, features we're working on now, and features that have not yet started. Somewhere in that list is a red line that says "we can launch now". You can directly measure velocity in terms of how many features are left until you are in the green.
I want to be clear that I think rough-order-of-magnitude estimates on work-in-progress and future work are perfectly fine and reasonable for internal use. What I am against is the use of deadlines and dates to manage the project as a whole. The goal is to deploy features, and that will take as long as it takes, and no amount of stomping of feet is going to change that, assuming you have a good team.
Ultimately what everyone wants is for the project to launch successfully. Software is very complex, and history (and theory) suggests that it is impossible to estimate accurately. The more time we spend on estimating, the less time we spend on working, and the more likely we are to miss our deadlines.
One final note. If you use JIRA, the backlog sucks (or at least it did when I abandoned it a few years ago). You need something that you can manipulate, that you can create different views, and that can collect information that helps you manage and prioritise it, since the backlog is orders of magnitude larger than the in-progress work and in my opinion is the actual problem that needs to be solved. I've personally used ProductBoard for many years but AirTable and even a spreadsheet is good.
I am keen to hear criticism and other ideas. My key thing is that saying "this feature should be finished by THIS DATE" is an absolute killer of productivity because of the amount of effort required to determine "THIS DATE" and the fact that the date is always wrong anyway.