not leaving much margin for error

That can be a huge plus and a life-saver sometimes.

a resignator

What's that?

if the surface mount pad will effect the resignator/ timing because of the pads?

Yes.

if I got the code right?

1. The code is very convoluted. I would keep a flag for data format (3 bytes vs. 2 byte read), and based on that flag, read the bytes out of the device.
2. When you reassembly the signed long type, you will need to test for sign (most significant bit of the most significant byte) and reverse the sign if necessary. So the bytes are reassembled to an unsigned long type, and if the number is negative, output its two's complement (aka a negative number).

I think the electronics can be challenging (more so from a reliabilty / redundance point of view), but the power sources are more so.

You probably will need to make some assumptions, without spending a lot of money. I would think of a few back-ups, like solar, geo-thermal, mechanism (wind + water), battery + capacitors, etc.

If all the device does is to keep time + go to sleep, its current consumption cannot be that big (ua range).

Yes and yes.

My telling you what to do doesn't help you, if you don't understand why you are observing what you are observing.

The original code isn't well documented but the following may help you understand what is happening:

Code:

unsigned int timerPeriod;

void startCounting (unsigned int ms)
...
  timerPeriod = ms;             // how many 1 mS counts to do
...
  startCounting (500);  // how many mS to count for
...
  float frq = (timerCounts *  1000.0) / timerPeriod;

Once you figure out the problem, the solution is right there.

Code:

startCounting (500);  // how many mS to count for

Would this have anything to do with your trouble?

Change the gate time.

Sounds like a great random number generator.

Code:

attachInterrupt(2, rotEncoder, CHANGE);  // ISR for rotary encoder on pin 2

INT0 is typically on PD2.

With that corrected, your code works.

although results sometimes flicker heavily

Because the code is poorly written.

All you need to do is to understand how this thing works, and code for it. The code posted earlier can serve as a good starting point: you will need to specify charge / discharge / measurement pins - for 6 leds, you need at most 7 pins.

The trick, with this approach, is to use time-out, so the measurement time isn't too long when it is dark.

A better approach is to use the adc module (aka charge transfer): it is much faster, offers higher resolution and is considerably simpler.

the lecturer told us a tale of this student who used many many NOP's for a delay loop.

Depending on the circumstance, it could be the smartest decision or the dumbest decision. Without knowing how the student arrived at this decision, it is impossible to assess.

I can get to my tacho wire

You will need to get a sense of what types of signals you are dealing with. My guess is that it is a pwm signal - most tachos are like that.

In that case, you will need to measure duty cycle + period.

It can be a one-timer or two-timer solution, depending on how you want to solve it.

Measuring weight isn't that difficult: a strain gauge for example.

Measuring mass is very challenging, electronically.

I am basically looking at what are the components that needs to be present in the circuit.

Too  many ways to do it, depending on your requirement.

The most pin-intensive would be to use 8-pins to drive the segments, and 4 pins to drive the digits.

From there, you can use a shift register to drive the digits; or to drive the segments; or to drive both.

You can also use dedicated ics for that, further reducing the pin counts.

Is this possible

Yes.