but it was never used as a way to assess fees
If you know the transaction priority, then you sort your transactions by this priority. Which means, that transaction with priority 1,000,000 is put lower in the queue than transaction with priority 2,000,000. Also, as an experiment, you can just grab the current mempool, apply those rules, and see, which transactions are selected, and which are skipped. You could be surprised.
it didn't decide what non-zero fee they had to pay
Only because we didn't reach the maximum size of the block yet, when this rule was active. But in general, that kind of rule can be used, for example as a starting point, to see, how well or bad it is selecting transactions.
it's mandatory to pay the fee that is calculated
No fee rules can enforce it. Even if you change consensus rules to enforce fees (which I think is a bad idea, because why miners shouldn't be able to pay zero fees, if they are going to collect those fees in the coinbase transaction anyway?), then still: it is possible to make an artificial traffic, only to meet your rules, and this is probably not what you want. Say, a transaction X would be forced to pay 0.01 BTC. Then, transaction X could pay that, but the miner could send 0.01 BTC back to the user, just to override some stupid fee policy. And it is possible to join those payments, then both will be accepted, or none, so it will be trustless.
Also, we had some altcoins, which were advertised, for example as "feeless". Guess what: people still have to pay: not with coins, but with time instead.
Another case was some exchange, which charged too huge fees. Guess what: it was exploited, when miners sent to them some payments, using a lot of small coins, so the exchange was forced to pay those miners back, when moving received coins.
So, to sum up: you can enforce your own fee policy. But you cannot expect, that everyone will be forced by consensus rules to follow it. The best you can do is making a new "de-facto standard", similar to "1 sat/vb", which we have today.
int(total_value/100)+1
Then, it will hurt you in the long-term scenario, where you will send a single satoshi, and pay a single satoshi as your fee. Which means: you will be forced to pay 100% fees in that case.
In general, percentage-based fees is one of the reasons, why I stopped using some LN channels. Above some amount, it was just more profitable to pay size-based fees, than amount-based fees. And then, some of my coins simply left LN, because if you have 0.01 BTC, and your fee is 0.1%, then you pay 1k satoshis. While on-chain, with a minimal fee rate, you can get it confirmed for much less than that (I had some batched on-chain transactions, when I paid 80 satoshis per output, and LN was unable to compete with that, because of percentage-based fees in some channels).
Also, your code may explode, where "total_value" will be zero, because then, you will be forced to pay a single satoshi anyway (created out of thin air?). I hope you won't decrement some zero-filled uint64_t, and you won't repeat Value Overflow Incident in that case.