I work for some event ticketing business and I'd sign this. My bosses want features quickly. Does not matter to them if I need extra time to make stuff secure, doesn't matter to them if it wont scale. Its about short term revenue. Can always rebuild the software to fit the next short term goal...
If you understand what are the metrics being tracked, and what are the primary goals that an initiative or product has, you can make a case.
We are an engineering discipline and engineering decisions can have revenue making implications. But it is hubris to assume why you should care about the nitty gritties of a codebase. It's the same way no one in leadership cares about the nitty-gritties of HR policies or accounting practices - people are hired to deal with the intricacies.
When I was a PM, I didn't have a difficult time making a business case for "keep the lights on" or tech debt work so long as I was able to attach tangible revenue implications (eg. X customer might churn because of subpar experience and we have both customer testimony and user stats showing that) or roadmap implications (eg. If we spend 6 months refactoring our monorepo, we can add new revenue generating modules every quarter instead of annually).