Note that if you have a unique ID for each item, this may not be appropriate if it's not what a user themselves would primarily associate with that item, or the main feature they would generally sort/look for an item based on. Default column arrangement needs to be approached not from your context, but from the user's.
@Xabre's answer provides more details/source articles related to scanning and recognition.
In terms of control placement and format, there is always a conundrum between the visual load created by filling a portion of a screen with repeated controls (particularly when scrolling) and with speed of using those controls, along with making sure the controls are explicit enough in their action identification that they do not cause confusion.
Frequently, inline controls are made smaller or with simple icons, in order to fit within the space they're restricted to. This can be problematic for discoverability for people who are unfamiliar with your application. Even when you feel you have used icons whose purpose should be self-evident and which are relatively consistent globally to other similar applications.
A drop-down or accordion can have a great deal of success here, if the task related to this set of data is likely to only be performed once per list view. At that point, the primary time factor is likely to be finding (search) the correct row to operate on, and a small loss in time due to having to click to open the controls is likely to not be an issue.
Another strong option to consider (in fact, it's the selected answer for the question you linked) is having each row be selectable, with a set of operation controls provided in the top or bottom of the screen/pane which perform the associated action on all selected rows. Make sure to provide appropriate de-selection (and possibly select-all) controls if doing this.
I generally recommend locating all actions which will not change the current view context at the top of the data set pane, in order to clearly promote what actions can be taken on the following set of data. This also keeps the controls consistent with familiar paradigms in similar action-heavy list controls such as file tree viewers.
Google Inbox provides a fairly strong example here, with four primary controls and an ellipses dropdown menu exposed across the top when in multi-select mode, for performing actions across the entire selection set:
Note that while Google does locate the checkboxes for row selection on the left, their uniformity, small size, and otherwise low visual impact mean it is still very easy to scan down the left column for desired email titles. Their simple and repetitive nature helps them be easily attenuated visually and mentally without competing overly in the search task as distractors.
It is also possible to do row selection via having the user directly click/touch the row itself in order to highlight it (see the Windows Explorer example farther above) but be sure that it is clear to the user that this interaction mode is available and that it won't lead to changing the view context/navigating away. I usually prefer checkbox controls over this as they are more self-evident in their available interaction: it can be difficult to provide appropriate cues for discoverability without apprehension in multi-selects which appear to be a normal list of items (rather than a clearly self-contained multi-select control) short of using something like a checkbox control.
It's possible to mix both patterns, and have individual controls exposed via something like hover or expansion (such as when "opening" an email in google inbox, see below, which forces the controls to stay visible rather than only showing on hover) on each item, while alternatively being able to select multiple items (rows) and then operate on them from a top bar of commands. It is important that these modes block each other to avoid confusion: otherwise users can be left questioning what will happen when they use the controls on an individual row when multiple rows are selected.
This can particularly be a decent compromise between aesthetic choices and usability concerns. Alternating and/or multiple modalities of operation can be a two-edged sword in terms of usability. While offering more options for accomplishing a task provides flexibility to different approaches from people using it, it can also create confusion, particularly inter-user confusion. Personally, I think in this case these both have enough global conformity in terms of the presence of paradigm and shared context to be acceptable when presented together for most people, but it can be something to keep in mind.
Note: this isn't trying to claim Google Inbox is fantastic UX across the board, but it provided an apt example for this discussion. Note also the use of controls for each item along the right-hand side.