Should Stories & Bugs Follow Different Workflows?
The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.
For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields. Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/s, Steps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.
The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.
Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.
I hope this explanation helps you avoid unnecessary workflows!