and then i'd need to use bit masks to actually use the data in the contract because there does not seem to be an equivalent to abi.decode() for abi.encodePacked()

They're more than happier to increase the oppcode costs for the nth time instead of addressing other issues.

don't

okay, so MAYBE ... just MAYBE it's actually cheaper to waste all that storage space, right?

nope, it's not

i wrote these two contracts to test it:

contract ParameterGasTestA {
address public a;
uint32 public b;
bool public c;

function doStuff(address _a, uint32 _b, bool _c) external {
(a, b, c) = (_a, _b, _c);
}
}

contract ParameterGasTestB {
address public a;
uint32 public b;
bool public c;

function doStuff(uint256 combined) external {
address _a = address(uint160(combined & 0x00ffffffffffffffffffffffffffffffffffffffff));
uint32 _b = uint32((combined >> 160) & 0xffffffff);
bool _c = ((combined >> 192) & 1) == 1;

(a, b, c) = (_a, _b, _c);
}
}

the one containing the absolute shit show is cheaper to run

in fact, for some reason only vitalik himself knows the one containing the absolute shit show actually even is 6'000 gas cheaper to deploy

The first contract is more expensive to execute because the function has 3 arguments, and to get them, evm does a lot of actions, which increases the size of the bytecode. Since the bytecode is bigger, the deploy will be more expensive