Used a second channel as Volker suggested. This is what I ended up running with:

package main

import (
    "log"
    "time"
)

// Run the function every tick
// Return false from the func to stop the ticker
func Every(duration time.Duration, work func(time.Time) bool) chan bool {
    ticker := time.NewTicker(duration)
    stop := make(chan bool, 1)

    go func() {
        defer log.Println("ticker stopped")
        for {
            select {
            case time := <-ticker.C:
                if !work(time) {
                    stop <- true
                }
            case <-stop:
                return
            }
        }
    }()

    return stop
}

func main() {
    stop := Every(1*time.Second, func(time.Time) bool {
        log.Println("tick")
        return true
    })

    time.Sleep(3 * time.Second)
    log.Println("stopping ticker")
    stop <- true
    time.Sleep(3 * time.Second)
}

The ticker creates a buffered channel with a capacity of one. The ticker drops time values when the channel is full.

Here's the timeline for the trace in the question. Events listed for the same time happen a tiny bit after each other in the order listed.

1s - ticker sends value
1s - main goroutine receives first value
1s - main goroutine starts sleep for 5s
2s - ticker sends value (channel has capacity 1).
3s - ticker fails to send value because channel is full
4s - ticker fails to send value because channel is full
5s - ticker fails to send value because channel is full
6s - main goroutine exits sleep and receives buffered value
6s - ticker sends value
6s - main goroutine receives buffered value

The ticker and main goroutine race to the 6s mark because the sleep is a multiple of the ticker period. In your trace, the main goroutine wins the race. On my machine, the ticker wins the race and I get the timing that you expect. Here's what it looks like on my machine.

...
5s - ticker fails to send value because channel is full
6s - ticker fails to send value because channel is full
6s - main goroutine receives buffered value
7s - ticker sends value
7s - main goroutine receives value

The ticker wins the race to the 6s mark on the playground. Run it here. The main goroutine wins the race when the sleep time is nudged down by a 1µs. Run it here.

This is easy to see when the sleep duration is not a multiple of the ticker period. Here's what happens when the sleep duration is 2.5 seconds:

1s - ticker sends value
1s - main goroutine receives first value
1s - main goroutine starts sleep for 2.5s
2s - ticker sends value
3s - ticker fails to send value because channel is full
3.5s - main goroutine exits sleep and receives buffered value
4s - ticker sends value
4s - main goroutine receives value

Run the last example on the playground.

Since this is a pretty simple function, I assume you are just using this as an example of how to mock non-trivial stuff. If you actually wanted to test this code, rather than mocking up ticker, why not just use really small intervals.

IMHO the 2nd option is the better of the two, making a user call:

foo(dur, NewTicker(interval)... 

doesn't seem like much of a burden.

Also having the callback is serious code smell in Go:

func Countdown(ticker Ticker, duration time.Duration) chan time.Duration {
    remainingCh := make(chan time.Duration, 1)
    go func(ticker Ticker, dur time.Duration, remainingCh chan time.Duration) {
        for remaining := duration; remaining >= 0; remaining -= ticker.Duration() {
            remainingCh <- remaining
            ticker.Tick()
        }
        ticker.Stop()
        close(remainingCh)
    }(ticker, duration, remainingCh)
    return remainingCh
}

You could then use this code like:

func main() {
    for d := range Countdown(NewTicker(time.Second), time.Minute) {
        log.Printf("%v to go", d)
    }
}

Here it is on the playground: http://play.golang.org/p/US0psGOvvt

As per my comment:

for {
   select {
      case <-time.After(time.Second * 5):
         ...
      default:
         ...
   }
}

Will create a new timer (time.After) each iteration. This means that the timer will never fire (because the default) case will always be selected. You can prevent this by creating the timer outside of the loop (playground):

timer := time.After(time.Second * 5)

myLoop:
for {
   select {
      case <-timer:
         break myLoop
      default:
         ...
   }
}

Your second example worked OK for me (see the previously referenced playground). Note that I'm unsure if any of these will accomplish the result you are looking for because that was not really defined.

The reason this does not work in the https://play.golang.org/ is because time.Tick(...) is a dirty function, which is only safe to be used in an infinite loop that ends with the app (or other use cases where you don't mind leaking memory). As per Golang documentation:

Tick is a convenience wrapper for NewTicker providing access to the ticking channel only. While Tick is useful for clients that have no need to shut down the Ticker, be aware that without a way to shut it down the underlying Ticker cannot be recovered by the garbage collector; it "leaks". Unlike NewTicker, Tick will return nil if d <= 0.

So generally it's better to use time.NewTicker(...) instead. See example at: https://pkg.go.dev/time#example-NewTicker

UPDATE: After Go v1.23 the Go compiler has removed the above limitation, so now both versions are ok to be used:

Before Go 1.23, this documentation warned that the underlying Ticker would never be recovered by the garbage collector, and that if efficiency was a concern, code should use NewTicker instead and call Ticker.Stop when the ticker is no longer needed. As of Go 1.23, the garbage collector can recover unreferenced tickers, even if they haven't been stopped. The Stop method is no longer necessary to help the garbage collector. There is no longer any reason to prefer NewTicker when Tick will do.