Able to reproduce this issue on reported version 69.0.3453.3 using Mac 10.13.3 with steps mentioned in comment#0, i.e; Not seeing highlight on using shortcut keys.

Good Build: 69.0.3452.0
Bad Build: 69.0.3453.3

Suspecting 8f2f9568808ee117698e0a9008a0b52902d2363e from changelog.

@erikchen: Please confirm the bug and help in re-assigning if this is not related to your change. Adding RB-Stable as this is recent regression.

NOTE: This issue might be duplicate of  issue 851257  which has same cl. On hitting cmd+c opens devtools instead of copying and cmd+shift+n opens new window instead of incognito.

@4: Thanks for your comments.

The "CMD-C" issue is tracked in  bug 850895 .

The "CMD-SHIFT-*" issue is tracked in  bug 851259 .

Thanks, both are now resolved (as of 3 days ago). I believe this issue can now be closed?

There's still making sure the menubar lights up.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/41281cd0bc3d09a8ce2b9c285c76870e4838f181

commit 41281cd0bc3d09a8ce2b9c285c76870e4838f181
Author: erikchen <erikchen@chromium.org>
Date: Wed Jun 20 18:15:05 2018

macOS: Fix menu-bar highlighting during keyEquivalents.

-[NSMenu performKeyEquivalent:] uses private APIs to highlight the menu for
100ms when the keyEquivalent: is activated. Rather than attempting to use the
private APIs, we simply let the NSMainMenu handle the event by returning NO from
-[NSWindow performKeyEquivalent:].

Bug:  851317 
Change-Id: I7f71023a4e37e0f89cb4f5e2f34fb1d95149629f
Reviewed-on: https://chromium-review.googlesource.com/1105067
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568929}
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/global_keyboard_shortcuts_mac.h
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/global_keyboard_shortcuts_mac.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/global_keyboard_shortcuts_mac_unittest.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/ui/cocoa/accelerator_utils_cocoa.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/ui/cocoa/browser_window_cocoa.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/ui/cocoa/browser_window_utils.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/ui/cocoa/chrome_command_dispatcher_delegate.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/chrome/browser/ui/views/frame/browser_frame_mac.mm
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/ui/base/cocoa/command_dispatcher.h
[modify] https://crrev.com/41281cd0bc3d09a8ce2b9c285c76870e4838f181/ui/base/cocoa/command_dispatcher.mm

This seems fixed in Cocoa but the issue is still seen in the MacViews Browser.

69.0.3469.2 (Official Build) canary (64-bit)

In fact this regressed again in MacViews:

You are probably looking for a change made after 569278 (known good), but no later than 569304 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/9695062bc8c6a7a95ae302bf52b9ffa834f96979..8c6e50ac487f07bc090d3272c7f19ac81a49e230

That revision range has https://chromium.googlesource.com/chromium/src/+/3be9df1c51294f066b0f3b6ecc389421b76d287d on it. I guess that's by design, to make "important" shortcuts more responsive. Do you see it regressing for all shortcuts, or only for new tab / close tab / switch tabs? Would you rather that those keys are more responsive, or that they blink the menu?

Gosh, I don't know. I'd like Chrome to be fast :)
I reported this issue because it looked jarring to not see the menu blink. I certainly can't say what's the right tradeoff. All I can say is that 68 is pretty snappy when it comes to holding down Cmd-T and Cmd-W.